Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
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 Nov 23 '11 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 Nov 26 '11 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 Nov 26 '11 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 Dec 4 '11 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 Dec 4 '11 at 20:32

2 Answers 2

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.
share|improve this answer
    
How can I do this when the systems have dynamic IP addresses? Would I have to assign static addresses? –  Rena Dec 10 '11 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 Dec 10 '11 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 Dec 15 '11 at 12:19

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.

share|improve this answer
    
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 Dec 4 '11 at 3:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.