>A CIFS root mount currently requires the use of SMB1+UNIX Extensions
which is only supported by the Samba server. SMB1 is the older
deprecated version of the protocol but it has been extended to support
POSIX features (See [1]). The equivalent extensions for the newer
recommended version of the protocol (SMB3) have not been fully
implemented yet which means SMB3 doesn't support some required POSIX
file system objects (e.g. block devices, pipes, sockets).
As a result, a CIFS root will default to SMB1 for now but the version
to use can nonetheless be changed via the 'vers=' mount option. This
default will change once the SMB3 POSIX extensions are fully
implemented.
Who thought re-enabling uses of SMB1 was a good idea?
SMB1 has to be used any time you need the POSIX extensions, with Samba at the server side and Linux at the client side.
I find it comes up reasonably often, because Samba is so configurable. For example remapping user ids, or mapping user-group permission bits; these are hard or impossible to do in NFS, depending on available NFS server version.
As mentioned, if you like Kerberos. It's not the nicest way to do anything. Kerberos is also only supported if you (can) use NFSv4, NFSv3 doesn't support Kerberos on all clients.
I like Kerberos a good bit and I think the complexity of running an LDAP/Kerberos infrastructure is greatly over estimated, but it is disappointing that none of the theorized alternatives ever really appeared. Last I read, LIPKEY was the only serious contender and there were some security concerns that got it nixed.
And if you don't use Kerberos, NFS has no authentication. For extra credit, it's generally paired with NIS, so everyone can see everyone else's password hashes. What's not to like for an attacker?
As a result, a CIFS root will default to SMB1 for now but the version to use can nonetheless be changed via the 'vers=' mount option. This default will change once the SMB3 POSIX extensions are fully implemented.
Who thought re-enabling uses of SMB1 was a good idea?