NFS: sec=sys or ruin your day

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.

7 thoughts on “NFS: sec=sys or ruin your day”

  1. 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.

  2. 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.


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

  4. 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)

  5. wow – thanks! I was banging my head against the table for 8 hours today trying to figure out what was going on!

    1. either you’re wasting your spare time or the time your employer is paying for.
      Sinking days into these typical debian issues just doesn’t cut it.
      summary: people need to just stop using debian.

      1. Christoph Haas

        Debian is one of the few dependable server operating systems. And probably the only one that is freely available. NFS has had problems ever since.

        And please stop trolling. You don't sound like you have ever worked in free enterprise. Else you would know where time is wasted… and that is much rather stupid management, bad company culture, a bad product or too many PowerPoint meetings. I would have to see a company that went bancrupt by their choice to use Debian. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *