Winbind/AD/NFSv4: Can’t `ls/cd` Private Directory?

Home » CentOS » Winbind/AD/NFSv4: Can’t `ls/cd` Private Directory?
CentOS No Comments

Hello everyone,

We have a CentOS 6.3 NFSv4 server and client, and we’ve run into a situation where the client is unable to list “private” (chmod 700-ed) directories, even if the current user owns the directory in question.

A bit more background: we’re also using Samba 3.5+Winbind to provide authentication and UID/GID mapping against a Windows 2008 R2 domain controller. I’ve been asked to get Kerberized NFSv4 working, but this problem occurs on mounts both with and without Kerberos, so I won’t torture anyone with the Kerberos part. :-)

ID mapping works:

[joeuser@nfsclient ~]$ id joeuser uidV055(joeuser) gide02(domain users) groupse02(domain users),1000001(BUILTIN\users)

Mounting directories -o sec=none works:

[joeuser@nfsclient ~]$ sudo mount -t nfs4 -o proto=tcp,port 49 -o sec=none /mnt

[joeuser@nfsclient ~]$ ls -l /mnt drwx—— 2 user1 domain users 4096 Aug 3 11:43 user1
drwx—— 2 adbinder domain users 4096 Aug 17 15:20 adbinder drwx—— 2 joeuser domain users 4096 Aug 3 11:43 joeuser

… however, we can’t seem to track down why this happens:

[joeuser@nfsclient ~]$ cd /mnt/joeuser bash: cd: joeuser: Permission denied

We have the same issue when mounting -o sec=krb5p, which yields slightly more interesting debug output[2].

Both hosts are running CentOS 6.3:
$ uname -a ; cat /etc/redhat-release ; rpm -qa | egrep “(samba|winbind|nfs)”
Linux nfsserver 2.6.32-279.2.1.el6.x86_64 #1 SMP Fri Jul 20 01:55:29 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux CentOS release 6.3 (Final)

Out of curiosity, I tried the same AD/Winbind/NFSv4 setup on Fedora 17 and had the same results when mounting either -o sec=none or -o sec=krb5/i/p:

$ uname -a ; cat /etc/redhat-release ; rpm -qa | egrep “(samba|winbind|nfs)”
Linux nfsserver-fedora 3.5.2-1.fc17.x86_64 #1 SMP Wed Aug 15 16:09:27 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Fedora release 17 (Beefy Miracle)


* Is this an ID mapping problem of some kind?
Many of the mailing list posts and bug reports that I’ve read pertaining to this problem usually stem from ID mapping failure, but it seems to be working in our case[4][5].

* Is it possible that this is an AD/Kerberos problem even though we’re mounting -o sec=none and Kerberos is supposedly not involved?
A recent linux-nfs mailing list post[0] described a similar problem when mounting, but the fix had no effect for us. (Once again, I tried mounting -o sec=none and -o sec=krb5/i/p).

* Since we’re relying in W2K8R2 for ID mapping, is there something extra we need to do to our least-privilege bind account[3]?

We would greatly appreciate any advice that you NFSv4 experts out there could offer. I would be happy to pass along more details/logs/debug/puzzle pieces if needed.

Many thanks,