[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