nfs idmap change
I recently rebooted a squeeze client which does nightly backups to a
squeeze nfs server with exports (rw,no_root_squash) using rsnapshot (with
cmd_cp) and started getting nightly mail from cron that:
rsync: chown "/the_mount/daily.0/etc/fetchmailrc" failed:
Invalid argument (22)
The only thing that had changed recently was the server had been upgraded
to kernel 2.6.39-bpo.2-amd64 .
ls -l and ls -n of the problem file on the client gives:
-rw------- 1 fetchmail root 416 Jun 12 2010 /etc/fetchmailrc
-rw------- 1 110 0 416 Jun 12 2010 /etc/fetchmailrc
The server's /etc/passd contains:
nut:x:110:118::/var/lib/nut:/bin/false (same uid different user)
and fetchmail was not installed on the server.
I tried installing fetchmail on the server (but not running it). In the
next nightly backup, the error message went away. But then ls -l and
ls -n of the backed up file showed:
-rw------- 17 fetchmail root 416 Jun 12 2010 /serverdir/fetchmailrc
-rw------- 17 111 0 416 Jun 12 2010 /serverdir/fetchmailrc
but viewed nfs mounted from the client:
-rw------- 17 fetchmail root 416 Jun 12 2010 /mountedOnClient/fetchmailrc
-rw------- 17 110 0 416 Jun 12 2010 /mountedOnClient/fetchmailrc
Despite /etc/rsnapshot.conf having "rsync_long_args --delete
--numeric-ids", it was using the non-numeric user name to translate the
numerical ids! It didn't do this before.
I created a test file on the server with user nut:
-rw-r--r-- 1 nut root 0 Jan 20 14:02 /serverdir/junk
-rw-r--r-- 1 110 0 0 Jan 20 14:02 /serverdir/junk
viewed nfs mounted from the client shows as:
-rw-r--r-- 1 nobody root 0 Jan 20 14:02 /mountedOnClient/junk
-rw-r--r-- 1 65534 0 0 Jan 20 14:02 /mountedOnClient/junk
since it can't find user nut on the client, it maps to nobody!
Then I uninstalled fetchmail from the server, rebooted to 2.6.32 and then
rebooted the client. The old behavior was restored: no more cron rsync
error and ls -n showing uid 110 on server and from client nfs mount.
The Squeeze backport of linux-image-3.1.0-0.bpo.1-amd64 became available
so I tried booting into that. It exhibited the same behavior as 2.6.39 .
Something has changed in kernel nfs idmap implementation. In
linux-doc-3.1 there is idmapper.txt.gz which discusses changes if
NFS_USE_NEW_IDMAPPER is set in the kernel. It is not set in the
backported kernel. The program /usr/sbin/nfs.idmap it discusses is not
found. I had played with /etc/idmap.conf and /etc/default/nfs-common
settings but only succeeded in breaking things. man rpc.idmapd has a -C
option but it is not clear how to set it in /etc/idmap.conf or whether
it addresses this.
Going forward with kernels, will there be a way to configure nfs idmap
for the previous functionality? Or will I have to mount differently
such as using sshfs instead of nfs?
Reply to: