rsync gibt "chown <…> failed: Invalid argument (22)" mit nfs share an

Ich versuche, mein gesamtes System mit rsync über ein Shell-Skript, das als root ausgeführt wird, auf einer externen Festplatte zu sichern:

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

Dieses Skript läuft auf der Maschine "akira". Ursprünglich war / home / rena / video eine USB-Festplatte, die direkt an akira angeschlossen war, und das Skript funktionierte einwandfrei.

Kürzlich habe ich die Festplatte verschoben; Jetzt ist es auf demselben Pfad auf einem anderen Computer "yuki" montiert und wird über NFS freigegeben. Also bezieht sich akira: / home / rena / video immer noch auf dieselbe USB-Festplatte, nur dass sie jetzt an yuki angeschlossen und über nfs geteilt wird, anstatt direkt an akira angeschlossen zu sein. Die Festplatte verwendet ext3 und ist mit Truecrypt verschlüsselt.

yukis / etc / export ist:

/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)

Jetzt gibt rsync für jede Datei einen Fehler aus:

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

nfs scheint zu "quetschen", obwohl es nicht gesagt wird?

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

von akira unterscheiden sich UID und GID; Vielleicht der Grund für das Versagen von rsync?

[Bearbeiten] Tatsächlich sieht es so aus, als hätte jede Datei auf der Freigabe UID und GID 65534 / Nobody.

backup rsync nfs

— Rena
quelle

Dies sieht so aus, als ob die Benutzer-IDs auf beiden Systemen nicht übereinstimmen (wie Sie bereits angegeben haben). Und dann scheint das Zielsystem die UID 22 nicht zu mögen. Können Sie eine Chown 22 für eine Datei bei yuki lokal ausführen? Versuchen Sie, SSHD im Debug-Modus auf Yuki auszuführen - vielleicht können Sie sehen, was dort passiert.

— Nils

@Nils ist chown 22 testauf Yuki erfolgreich und die Änderung spiegelt sich in stat wider. Ich habe auf keinem System eine UID 22; Ich bin mir nicht sicher, woher diese Nummer kommt.

— Rena

Sie synchronisieren mit "--numeric-ids" - also gehe ich davon aus, dass die UID von Akira stammt. Haben Sie beim sshd-Debug etwas Interessantes gesehen?

— Nils

Ich finde keine Dateien mit UID 22 mit $ sudo find / -uid 22 -print. EINVAL ist allerdings der Fehlercode 22, also schätze ich, dass dies überhaupt keine UID ist ... Ich bin nicht sicher, wie ich den sshd-Debug-Modus mit nfs verwenden soll?

— Rena

Ich glaube nicht, dass dies ein SSH-Problem ist - nach Ihrem Update sieht es eher aus wie ein Root-Squash-NFS-Mount. Überprüfen Sie die Ausgabe Ihres NFS-Servers (Yuki), wenn Akira bereitgestellt wird. Auf welchen Namen bezieht sich Yuki, wenn Akira steigt? Wenn das nicht genau akira ist, funktioniert Ihre Exportoption (no_squash) nicht.

— Nils

Dies scheint ein Problem zu sein, das den Namen auf Ihrem NFS-Server (Yuki) löst.

Stellen Sie sicher, dass die Namensauflösung für Hosts in zuerst auf Dateien eingestellt ist /etc/nsswitch.conf
Wenn dies der Fall ist, /etc/host.confstellen Sie sicher, dass die Auflösungsreihenfolge auf Folgendes eingestellt ist:order hosts bind
Legen Sie die IPs Ihrer Clients /etc/hostsauf dem NFS-Server ab. Stellen Sie sicher, dass der Kurzname der erste Eintrag nach der IP ist.

— Nils
quelle

Wie kann ich das tun, wenn die Systeme dynamische IP-Adressen haben? Müsste ich statische Adressen zuweisen?

— Rena

Entweder dies (was für jeden Server eine gute Idee ist - um ihn von anderen Diensten wie dhcp unabhängig zu machen) oder Sie verwenden den vollständig qualifizierten Hostnamen auf yuki (wenn er gleich bleibt).

— Nils

Dies scheint geholfen zu haben, aber ich habe immer noch einige Dateien, die diesen Fehler auslösen, wenn ihre UID eine ist, die keinem Benutzer auf Yuki gehört. Es muss eine Möglichkeit geben, die UID / GID zu ändern, auch wenn am Ziel kein solcher Benutzer / keine solche Gruppe vorhanden ist. Ich dachte - numerische IDs würden das tun ... (und von akira aus gesehen ist ihre UID 65534 / niemand, aber auf Yuki, 114 / UNBEKANNT. 114 ist eine gültige UID auf Akira, aber nicht auf Yuki.)

— Rena

Angenommen, dies ist kein NFSv4, machen Sie anscheinend eine anonyme Freigabe, und da standardmäßig keine Übereinstimmung von uid / gid vorliegt, wird niemandem / nogroup zugewiesen.

— Schrägstrich
quelle

Es scheint nfs4 zu sein, wie Mount zeigt: yuki:/home/rena/video on /home/rena/video type nfs (rw,vers=4,addr=192.168.1.67,clientaddr=192.168.1.66)

— Rena