Mounting remote directories/shares

Daniel Fussell dfussell at
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 mailing list