Mounting remote directories/shares
dfussell at byu.edu
Thu Sep 26 12:31:13 MDT 2013
On 09/26/2013 08:32 AM, Michael Torrie wrote:
> NFSv4 changes things somewhat, if you add Kerberos to the mix. I never
> quite got around to learning how to set that up, but there are docs and
> howtos out there.
NFSv4 with Kerberos does remove the problem of trusting the client
provided uid, but still requires that the client machine is a known,
registered principal (essentially a computer account, same as AD's
kerberos). It takes some time to get the kerberos principals set up
correctly. As I recall, the usernames on the server and client still
have to match. AUTH-SYS is still available (NFSv3 style) with all the
same ramifications. LIPKEY and SPKM-3 were proposed alternatives to
Kerberos, but were never implemented due to security concerns.
The down side of NFSv4 is you lose all the wonderful simplicity of NFSv3
w/ posix draft ACLs (not to be confused with standard unix mode bits).
Your server would still enforce posix acls, but you wouldn't be able to
see or modify them over NFS. NFSv4 does have it's own windows-ish ACLs,
but only ZFS on solaris and GPFS (on AIX?) can store and use them.
There's been some work on adding NFSv4 ACLs to ext3 (richacls), but the
patches never made it into the kernel, and I don't think they ever
really stabilized in the first place. There has been talk about
extending ext4 and XFS to support the new ACLs, but nothing has been
At one time there was talk of translating between the ACL types, but it
became quickly apparent that posix draft couldn't do everything NFSv4
ACLs could (not that you'd want to, of course), and would lead to
confusing failures; situations like an application setting an ACL, and
then reading it back to confirm it was set. The ACL it got back would
likely be different, and the translation may also fail by giving too
much or too little access.
So far, the linux community has been content with NFSv3 and posix ACLs
on the server, and NFSv4 as a fully supported client for connecting to
some other vendor's server. Until someone figures out a way to support
both acl types from disk to client and back, I don't see NFSv4/4.1/4.2
ever really taking off, despite their other wonderful features*
*I came across something yesterday that said the optional Parallel NFS
features were not implemented in the Linux kernel server, and the
developers have moved on to implementing the latest, greatest NFSv4.2
features instead (like server->server copy as directed by a client).
Kind of sad really, pNFS looked pretty cool, even if the metadata server
was a single-point-of-failure.
More information about the PLUG