7

I'm trying to back up my entire system to an external disk using rsync, via a shell script which is run as root:

#!/bin/bash
rsync -vSHPhhaX --numeric-ids --delete --exclude-from=/home/rena/.scripts/exclude-list / /home/rena/video/.backup/>/home/rena/video/.backup.log

This script is running on the machine "akira". Originally, /home/rena/video was a USB hard disk attached directly to akira, and the script worked fine.

Recently I moved the disk; now it's mounted at the same path on another machine "yuki", and shared via NFS. So akira:/home/rena/video still refers to the same USB hard disk, only now it's attached to yuki and shared via nfs, instead of attached to akira directly. The disk is using ext3 and encrypted with Truecrypt.

yuki's /etc/exports is:

/home/rena  akira(rw,subtree_check,nohide,no_root_squash) rei(rw,subtree_check,nohide,no_root_squash)
/home/rena/video    akira(rw,subtree_check,nohide,no_root_squash) rei(rw,subtree_check,nohide,no_root_squash)

Now rsync gives an error for every file:

rsync: chown "/home/rena/video/.backup/boot/System.map-2.6.38-8-generic" failed: Invalid argument (22)

nfs seems to be "squashing" even though it's told not to?

rena@akira $ stat /home/rena/video/.backup/boot/abi-2.6.38-10-generic
  File: `/home/rena/video/.backup/boot/abi-2.6.38-10-generic'
  Size: 730457          Blocks: 1440       IO Block: 65536  regular file
Device: 19h/25d Inode: 38822526    Links: 1
Access: (0644/-rw-r--r--)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)
Access: 2011-10-19 22:17:12.000000000 -0600
Modify: 2011-06-28 13:19:43.000000000 -0600
Change: 2011-10-19 22:17:12.000000000 -0600

rena@yuki $ stat /home/rena/video/.backup/boot/abi-2.6.38-10-generic
  File: `/home/rena/video/.backup/boot/abi-2.6.38-10-generic'
  Size: 730457      Blocks: 1440       IO Block: 4096   regular file
Device: fc04h/64516d    Inode: 38822526    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-10-19 22:17:12.000000000 -0600
Modify: 2011-06-28 13:19:43.000000000 -0600
Change: 2011-10-19 22:17:12.000000000 -0600

from akira, the UID and GID appear different; maybe the reason for rsync failing?

[edit] In fact it looks like from akira, every file on the share has UID and GID 65534/nobody.

Improve this question
6
  • This looks as if the user-IDs mismatch on both systems (like you already stated). And then the target system does not seem to like the UID 22. Can you do an chown 22 on any file at yuki locally? Try to run SSHD in debug-mode on Yuki - perhaps you can see what is happening there.
    – Nils
    Commented Nov 23, 2011 at 20:03
  • @Nils chown 22 test succeeds on Yuki and the change is reflected by stat. I don't have a uid 22 on either system; I'm not sure where that number comes from.
    – Rena
    Commented Nov 26, 2011 at 10:12
  • You rsync with "--numeric-ids" - so I assume that UID comes from Akira. Did you see anything interesting on the sshd debug?
    – Nils
    Commented Nov 26, 2011 at 21:16
  • I don't find any files having uid 22 with $ sudo find / -uid 22 -print. EINVAL happens to be error code 22 though, so I'm guessing that's not a UID at all... I'm not sure how to use sshd debug mode with nfs?
    – Rena
    Commented Dec 4, 2011 at 3:23
  • I don`t think this is an ssh issue - after your update it looks rather like a root-squash-NFS-mount. Check your NFS-server (yuki) output when akira mounts. What is the name yuki refers to when akira mounts? If that is not exactly akira your export-option (no_squash) will not work.
    – Nils
    Commented Dec 4, 2011 at 20:32

2 Answers 2

Reset to default
1

This seems to be a name resolving problem on your nfs-server (yuki).

  1. Make sure the name-resolving is set to files first for hosts in /etc/nsswitch.conf
  2. If there is a /etc/host.conf make sure that the resolving order is set to : order hosts bind
  3. Put the IPs of your clients into /etc/hosts on the NFS-server. Make sure the short name is the first entry after the IP.
Improve this answer
3
  • How can I do this when the systems have dynamic IP addresses? Would I have to assign static addresses?
    – Rena
    Commented Dec 10, 2011 at 7:03
  • Either this (which is a good idea for any server - to make it independent from other services like dhcp) or use the fully qualified hostname on yuki (if it stays the same).
    – Nils
    Commented Dec 10, 2011 at 21:43
  • This seems to have helped, but I still have some files throwing this error, when their uid is one that doesn't belong to any user on yuki. There must be a way to tell it to change the uid/gid even if no such user/group exists on the destination? I thought --numeric-ids would do that... (and again, viewed from akira, their uid is 65534/nobody, but on yuki, 114/UNKNOWN. 114 is a valid uid on akira, but not on yuki.)
    – Rena
    Commented Dec 15, 2011 at 12:19
0

Assuming this is not NFSv4 you are seemingly doing an anonymous share, and because there is no matching of uid/gid by default nobody/nogroup are assigned.

Improve this answer
1
  • 1
    It does appear to be nfs4, as mount shows: yuki:/home/rena/video on /home/rena/video type nfs (rw,vers=4,addr=192.168.1.67,clientaddr=192.168.1.66)
    – Rena
    Commented Dec 4, 2011 at 3:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .