NFS: sec=sys or ruin your day

Submitted by Christoph Haas on Tue, 01/13/2009 - 12:22

And once again I was bitten by problems on my Debian laptop mounting directories from the file server via NFS. After a Debian dist-upgrade I couldn't login to KDE any more. Shell login worked somehow but I quickly found out I could neither read nor write any files there. Apparently an "ls -al" showed me the right permissions (not just unmappable numeric UIDs or something of that kind) and an "id -a" confirmed that my LDAP PAM configuration still worked. But reading or writing any file just lead to "Permission denied".

I'm not sure if it was an update in the nfs-common package in Sid. But I had the same problem before and it took me hours until I finally figured out that Debian's NFS seems to use non-standard defaults. Namely the "sec" parameter when mounting the NFS share. According to the Solaris documentation the default is "sec=sys" which means that NFS uses the locally acquired UIDs and GIDs. Like /etc/passwd, NIS or LDAP/PAM. But on Debian it seems to default to "sec=krb5" or something. As I have close to no idea how to set up Kerberos and don't want to (and talking to other people hardly anyone has used Kerberos either) I figured that it's not really a sane default. I didn't even ask for NFSv4 - just NFSv3. Perhaps I undeliberately set some /etc/default/nfs-common configuration setting wrong or whatever. It was just strange. So I set "sec=sys" in the options of the NFS share of my /etc/fstab and the problem was fixed.

Actually I wonder what network file systems other people use in a Debian environment. NFS somehow feels antiquated to me anyway.

4 comments

Still on NFSv3 here and

Submitted by anonymous (not verified) on Tue, 01/13/2009 - 14:56.

Still on NFSv3 here and feeling very bad about it (Security, and also occasionally performance.) Looked at NFSv4 but its non-POSIX acl make a transition hard. Haven't looked at Samba which, I hear, is increasingly used for Linux-to-Linux file serving.

I thought there was a policy

Submitted by MJ Ray (not verified) on Wed, 01/14/2009 - 19:43.

I thought there was a policy reason for Kerberos support by default, but I can't find it anywhere so maybe I dreamt it!

Anything other than NFSv4 is

Submitted by Martin (not verified) on Sat, 01/24/2009 - 17:35.

Anything other than NFSv4 is just rubbish in corporate environments. I use NFSv3 on a closed systems (storage on cluster's private network) but other than that it's absolutely inappropriate.

I do have a working kerberos setup in order to use NFS4 on corporate network. at the moment it's used only for user's home directories, plan to use it for anything else failed because of the lack of NFSv4 acl support in debian. (no way to use unix group permissions)

Hi, I just read this on

Submitted by Toby (not verified) on Tue, 01/13/2009 - 16:06.

Hi,

I just read this on Planet Debian and thought I could mention another thing that I just manage to solve after several day of troubleshooting. When I tried to mount a NFSv4 share I got this: mount.nfs4: Cannot allocate memory

This is also on a sid client. I do not use the share on a regular basis so I'm not sure when it stopped working.

Solution was to modprobe ipv6 that I had on blacklist.

/Toby

The contents of this web site is Copyright © 2000-2011 Christoph Haas - Impressum/Imprints -  Donations welcome

Drupal theme by Kiwi Themes.