[SLL] overcoming NFS group limits

Derek Simkowiak dereks at realloc.net
Mon May 11 15:12:41 PDT 2009


2) Are there any alternatives to NFS?


    NFS It is the only well-established file sharing network protocol 
that natively supports the concept of Unix UIDs and GIDs.  Samba "SMB", 
Appletalk, WebDAV, etc. do not directly support the UIDs and GIDs of a 
Unix filesystem.  (There are various "mapping" solutions, but they're 
all ugly.)

    NFS is also a nightmare.  I've seen a mis-behaving NFS mount cause 
system failures (like server freezes) on at least three Big Production 
Systems.  The root cause is that NFS is implemented directly in the 
kernel (although, a user space NFS for Linux does exist).  There are 
various options to make NFS play nice, but when problems happen, they 
can be very serious -- like, you can't SSH in anymore kind of serious.

    You mentioned large files; if all your servers are in the same data 
center, you may want to consider moving from a TCP/IP networked 
filesystem to a shared backend storage, like a fiber SAN using the GFS 
filesystem.  But that's a major architecture change, and probably not 
what you're looking for.  (It would be a lot faster, though.)

    There is one alternative to NFS that supports the native Unix UIDs 
and GIDs: SSHFS.  SSHFS is a FUSE filesystem.  It allows any user to 
remotely mount a filesystem using SSH. 

    SSHFS runs in userspace, not in the kernel, so a dirty SSHFS mount 
won't kill your server.  Like NFS, SSHFS is smart about local caching.  
It's also smart about intermittent network connections.  My favorite 
feature is that SSHFS access can be controlled via SSH keys, which is 
light years beyond what NFS can offer in terms of security and 
management policies (*cough* "root_squash" *cough*).

    The one (and only?) drawback to SSHFS is that OpenSSH forces you to 
use encryption.  You'll see a roughly ~5% slowdown in file transfer 
speeds, due to the encryption and due to the fact it's user space 
instead of kernel space.  Personally, I'm willing to live with that 5% 
just to get key-based authentication.  The warm'n'fuzzy feeling that 
comes from knowing all my network traffic is encrypted is just icing on 
the cake...

    My advice is to try SSHFS and see what happens.


--Derek
http://cool-st.com/


On 05/11/2009 02:14 PM, Ted Stern wrote:
> This is more of a general Unix question, but I'm looking for a
> solution on a Linux server.
>
> If a user accesses an NFS-mounted disk, NFS supports only the first 16
> groups of which that user is a member.
>
> This might seem ample for most small systems, but I'm at a large
> company with lots of projects, and due to accounting rules a plethora
> of groups were created over the years.
>
> We've done a major group cleanup (which should have been done anyway)
> but there are still some users who, because of their involvement with many
> projects, have to be members of lots of groups.
>
> So, two questions:
>
> 1) Is there any hope that NFS will support more than 16 groups in the
> near future?
>
>
> 2) Are there any alternatives to NFS?
>
> 3) Are there any network mountable filesystems that have support for
> access control lists?  Note that the protocol has to be at least as
> fast as NFS because we're supporting multi-GB file access.
>
> Thanks,
>
> Ted
>   


More information about the linux-list mailing list