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? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnji64g1.5pf.alanjg@archduke.router
