Because they have nothing to do with being a file server, maybe? And in what way does this make it “pretty insecure,” as you claimed?
1 Like
You can put this in /etc/nsmb.conf for a global configuration, or ~/Library/Preferences/nsmb.conf to just affect the current user. On some Macs, especially with IPv6 enabled, it seems to be helpful to force the wired interface. Mostly, though, the biggest issue I’ve seen is that without forcing the protocol version and session encryption, many Mac and iOS devices will fail to connect to SMB shares if you force session encryption on the server side. This basically ensures the Mac does this on the client side as well. Depending on your version of Samba on TrueNAS and your OS, this may or may not be a problem for everyone, but it simplified things for me. YMMV.
[default]
mc_on=yes
mc_prefer_wired=yes
minauth=ntlmv2
comp_exclude_list=7z,bz2,bzip2,gpg,gz,zip,xz,zst
[truenas]
addr=truenas.local
force_sess_encryption=yes
force_share_encryption=yes
protocol_vers_map=4
Running VMs or applications in jails/containers has nothing to do with being a pure file server, either. This is a strawman argument.
NFS without centralized ID mapping is insecure from a permissions perspective. NFS without Kerberos-based TLS is insecure because the data is not encrypted in transit. That makes NFS without the additional components insecure in a general sense, and non-compliant without compensating controls in almost any regulated environment. For something that is intended to be an appliance, this is an unnecessary gap when it ships with the capabilities required built in but disabled.
In either case, an AD DC is an all-in-one solution for both problems. Meanwhile, Apple has removed the server software to run a Kerberos server from macOS, and doesn’t allow OpenDirectory to act as an identity server other than for the localhost. Linux would require you to set up either Samba as a DC on the network, or add NIS/LDAP + TLS-enabled Kerberos system(s) with valid certificates to work. This is non-trivial, especially if you have to create valid SSL certificates.
My point is that if your use case is an enterprise Windows network with an AD controller on a Windows server in a commercial environment, maybe you won’t care. For those implementing TrueNAS into a non-Windows SOHO or complex hobbyist network, then the lack of cross-system ID mapping and encryption-in-transit is insecure when NFS is enabled. Q.E.D.
It does if you have a use case for serving files over NFS. Some applications work better over NFS, and saying that you shouldn’t use NFS because SMB is available is not always a useful answer.
An appliance that offers NFS should offer the ability to use secure transports when supported. NFS can be secure when properly configured; so can Samba. Nothing is perfect, but saying “don’t use Samba, and don’t use NFS” turns an existing (if disabled) feature set into something where TrueNAS can’t meet a need that it could otherwise meet relatively easily.
1 Like
Wow. Personal attacks, much?
The typical straw man argument creates the illusion of having refuted or defeated an opponent’s proposition through the covert replacement of it with a different proposition (i.e., “stand up a straw man”) and the subsequent refutation of that false argument (“knock down a straw man”), instead of the opponent’s proposition.
I originally chose not to address the other informal fallacies in your post because arguing about it serves no purpose. You can acknowledge the use case and the security implications of using NFS without the disabled features to provide the security that NFS by itself can’t provide, or refute what I’ve actually said without resorting to various fallacies such as strawman arguments, ad hominems, appeals to ridicule, appeals to authority, and begging the question.
The fact is that NFS as currently shipped in TrueNAS is intrinsically insecure if enabled as-is. Enabling the built-in Samba DC functionality is only one potential control; there may be others that can be supported by the appliance through additional software packages or the use of other existing features like VMs or containers (all of which would require middleware support, as I understand it) and those would certainly be constructive comments. I will happily engage with you further if you have technical insights about better (or alternative) ways to support NFS securely with an appliance OS that supports the protocol and already has a built-in option (even if an imperfect one) that could serve.
Hardly.
Which is exactly what I did not do. You claimed that my “because AD services have nothing to do with being a file server” was a strawman, and it was not, even by the definition you quote. It may be a poor argument (though I don’t believe it was), but that doesn’t make it a strawman.
Your argument appears to be[1] that because TrueNAS doesn’t include all the necessary infrastructure to run NFS securely, that makes TrueNAS insecure. I find that a somewhat curious definition of “insecure.” If TrueNAS were incapable of integrating with such infrastructure, that’d be a different story, but that doesn’t appear to be what’s going on here.
and in that I’m attempting to represent your argument, here’s where I could possibly be presenting a strawman ↩︎