I am trying to backup files from one server, using another server which has a tape drive attached. I've done this many times before. The problem is, *this* time, root on the NFS client can't read the files on the NFS server. It appears that no_root_squash is being ignored.
I have two Debian systems: 1) NFS server: svr4 (jessie) 2) NFS client: arc1 (squeeze) (has tape drive) On the server (svr4) I have this line in /etc/exports: /home -no_subtree_check arc1(ro,no_root_squash,sync) On the client I use autofs, but for purposes of demonstrating the problem I will use manual mount commands. (Rest assured it breaks just the same with autofs mounts.) arc1:~# mount -v -t nfs svr4:/home /mnt mount.nfs: timeout set for Mon Aug 8 10:57:37 2016 mount.nfs: trying text-based options 'addr=10.76.142.85' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 10.76.142.85 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 10.76.142.85 prog 100005 vers 3 prot UDP port 58163 svr4:/home on /mnt type nfs (rw) arc1:~# ls /mnt/wooledg/Maildir ls: cannot open directory /mnt/wooledg/Maildir: Permission denied arc1:~# su wooledg -c 'ls /mnt/wooledg/Maildir' courierimapkeywords courierimapuiddb cur new tmp arc1:~# umount /mnt arc1:~# showmount -e svr4 | grep /home /home arc1.eeg.ccf.org So, the file system mounts correctly, and the non-root user can read the files, but root can't read them. I have rebooted both the client and server machines. I have tried restarting NFS services on them, too. I have done "exportfs -u -a" and "exportfs -a". I've done everything I can think of. This is very similar to what I see in bug #492970 and this past discussion: https://lists.debian.org/debian-user/2008/08/msg01943.html http://bugs.debian.org/492970 However, both of my systems are newer than the systems described in that bug report, and I don't think "downgrade to nfs-common 1.1.2" is a viable solution for me. Is there any package I might be missing on the new jessie server, either for general NFS operations, or specifically for compatibility with older Linux NFS clients? root@svr4:/# uname -a Linux svr4 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux root@svr4:/# dpkg -l | grep -E 'nfs|portmap|rpcbind' ii libnfsidmap2:amd64 0.25-5 amd64 NFS idmapping library ii nfs-common 1:1.2.8-9 amd64 NFS support files common to client and server ii nfs-kernel-server 1:1.2.8-9 amd64 support for NFS kernel server rc portmap 6.0.0-2 amd64 RPC port mapper ii rpcbind 0.2.1-6+deb8u1 amd64 converts RPC program numbers into universal addresses arc1:~# uname -a Linux arc1 2.6.28-1-amd64 #1 SMP Wed Feb 18 17:16:12 UTC 2009 x86_64 GNU/Linux arc1:~# dpkg -l | grep -E 'nfs|portmap|rpcbind' ii libnfsidmap2 0.23-2 An nfs idmapping library ii nfs-common 1:1.2.2-4squeeze3 NFS support files common to client and server ii nfs-kernel-server 1:1.2.2-4squeeze3 support for NFS kernel server ii portmap 6.0.0-2 RPC port mapper root@svr4:/# tail /var/log/daemon.log ... Aug 8 10:55:37 svr4 rpc.mountd[1312]: authenticated mount request from arc1.eeg.ccf.org:823 for /home (/home) Aug 8 10:56:05 svr4 rpc.mountd[1312]: authenticated unmount request from arc1.eeg.ccf.org:809 for /home (/home) ... One final note, though I don't know how it may relate: svr4 was just upgraded to Jessie on Friday, to replace a machine that died. I reused the same IP address. The machine that died was running Jessie but with a Wheezy kernel; it had been upgraded many times, originally installed from Lenny IIRC. This all worked fine on the old server. It is not working on the new server. It had crossed my mind that something was caching the old server's information due to the IP address reuse, but I have rebooted both systems since then, so that shouldn't be the case.
