rsync-Fehler: Fehler beim Einstellen der Zeiten für "/ foo / bar": Vorgang nicht zulässig

194

Ich erhalte einen verwirrenden Fehler von rsync und die ersten Dinge, die ich bei der Websuche finde (sowie alle üblichen Änderungen), lösen ihn nicht:

rsync: failed to set times on "/foo/bar": Operation not permitted (1)
rsync error: some files could not be transferred (code 23) 
  at /SourceCache/rsync/rsync-35.2/rsync/main.c(992) [sender=2.6.9]

Es scheint trotz dieses Fehlers zu funktionieren, aber es wäre schön, das loszuwerden.

rsync file-transfer

— träumt
quelle

Nein, nur ein normales Verzeichnis, soweit ich das beurteilen kann.

— Dreeves

Ich bin gerade auf ein ähnliches Problem gestoßen, obwohl mein Fehlercode 22 war: rsync: Fehler beim Festlegen der Zeiten für ... Ungültiges Argument (22). Nach einiger Überprüfung stellte sich heraus, dass meine Dateien als zuletzt geändert im Jahr 1956 datiert waren! Lösung: Berühren Sie alle Dateien, Problem behoben. :) "find. -print0 | xargs -0 touch"

— KIAaze

Ich finde, wenn Sie auch einen Cron-Job am selben Ziel eingerichtet haben, wird dieser Fehler angezeigt. Wenn Sie die Zeit für den Cron-Job (Crontab) ändern, können Sie dies umgehen. In meinem Fall wird dieser Fehler nur angezeigt, wenn ich einen manuellen Rysnc durchführe, wenn ich auch einen Cron-Job eingerichtet habe.

— NelsonGon

286

Wenn /foo/bares sich um NFS (oder möglicherweise ein FUSE-Dateisystem) handelt, ist dies möglicherweise das Problem.

In beiden Fällen wird durch Hinzufügen von -O/ --omit-dir-timeszu Ihrer Befehlszeile vermieden, dass versucht wird, Änderungszeiten für Verzeichnisse festzulegen.

— Jon Bright
quelle

8

Komisch ist, dass ich ext3 mit ext3 synchronisiere. Beide Betriebssysteme sind Linux. Ich musste diesen Schalter noch nie benutzen. -O hat den Trick gemacht, aber ich wünschte, ich müsste ihn nicht benutzen.

— d -_- b

3

Vielen Dank! Es stellt sich heraus, dass einige VPS-Hosts (z. B. xlshosting.nl) dies intern verwenden, was zu Problemen mit rsync führen kann.

— Frederik

2

Ich habe das gleiche Problem beim Synchronisieren von Linux ext4 auf Linux ext4: a "Zeiten können nicht festgelegt werden: Operation nicht zulässig" für Symlinks , nicht für Verzeichnisse. -Ohilft natürlich nicht. Dies war früher nicht der Fall, als meine Sicherungspartition ext3 statt ext4 war.

— Marius Gedminas

10

Ich habe rsync -avc verwendet und das Hinzufügen von -O hat nicht geholfen. Ich habe dann gelesen, dass -a das Äquivalent zu -rlptgoD ist, das -t enthält, was meiner Meinung nach -O überschreibt. Also für mich war das Update, -rlpgoDvc

— dlink

3

@dlink können Sie hinzufügen --no-t, um die implizite Option zu entfernen.

— Noam Nelke

86

Das Problem ist wahrscheinlich darauf zurückzuführen, dass / foo / bar nicht zum Schreibprozess auf einem Remote Darwin (OS X) -System gehört. Eine Lösung für das Problem besteht darin, einen geeigneten Eigentümer am Remote-Standort festzulegen.

Da diese Antwort abgestimmt wurde und daher hoffentlich für jemanden nützlich war, erweitere ich sie, um sie klarer zu machen.

Der Grund dafür ist, dass rsync wahrscheinlich versucht, beim Kopieren von Dateien eine beliebige Änderungszeit (mtime) festzulegen.

Um dies zu tun, utime()erfordert Darwins Systemfunktion, dass die effektive UID des Schreibprozesses entweder mit der Datei-UID oder der Super-User- UID identisch ist (siehe Seite opengroup utime) . Überprüfen Sie diese Diskussion auf der rsync-Mailingliste als Referenz.

— anddam
quelle

10

Gleiches gilt für Linux (in meinem Fall Debian Squeeze) ... Wenn ich nicht der Eigentümer des Zielverzeichnisses bin, gibt rsync die Fehlermeldung "Zeiten können nicht eingestellt werden" aus. (Schreibberechtigung für das Verzeichnis ist nicht genug.)

— ddekany

1

Ich bin in derselben Ausgabe gefangen. Bis zum Mounten von NTFS mit uid = user.

— Gavenkoa

3

Dieser Fehler wurde für mich behoben, als ich den Eigentümer des Verzeichnisses, auf das ich mich auswirken wollte (auf dem Remote-Server), mithilfe des Befehls rsync an denselben Benutzer änderte wie denjenigen, der versuchte, sich über rsync in meinem lokalen Bash-Skript anzumelden. Mit anderen Worten: Ich habe versucht, /remote/path/to/foo/barmit diesem Befehl auf den Remote-Server zu schreiben : rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ user1@1.2.3.4:/remote/path/to/foo/bar und habe die gleichen Fehlermeldungen erhalten, die user1/remoe/path/to/foo/bar$ chown -R user1 /remote/path/to/foo/bar

— verschwunden sind,

1

Wenn Sie Ihre Dateien für andere Benutzer in einer Gruppe freigeben, z. B. das Sticky-Bit, ist ein Eigentümerwechsel nicht die richtige Lösung. Wir verwenden -t und add -O nicht, um diese Warnung zu verhindern.

— R. van Twisk

1

Können Sie die Antwort erweitern, um herauszufinden, ob ein Benutzer Teil einer Gruppe ist, der die Datei / das Verzeichnis gehört, falls dies ODER nicht funktionieren sollte?

— Elijah Lynn

4

Wie @ racl101 auf einer Antwort kommentiert hat, kann dieses Problem mit den in Beziehung gesetzt wird Besitzer des Ordners . Der Befehl rsync sollte von demselben Benutzer ausgeführt werden wie der Befehl des Ordnerbesitzers. Wenn es nicht dasselbe ist, können Sie es ändern.

chown -R userCorrect /remote/path/to/foo/bar

— Lud Akell
quelle

2

Das Problem in meinem Fall war, dass der "Empfänger-Mountpoint" falsch montiert war. Es war schreibgeschützt (aus irgendeinem Grund). Es sah so aus, als würde rsync die Dateien kopieren, aber das war es nicht. Ich habe meine fstab-Datei überprüft und die Mount-Optionen auf Standard geändert, das Dateisystem erneut gemountet und rsync erneut ausgeführt. Dann alles in Ordnung.

— Ripah
quelle

2

Ich hatte das gleiche Problem. Für mich besteht die Lösung darin, die entfernte Datei zu löschen und rsyncerneut erstellen zu lassen.

— Shintaroid
quelle

0

Ich habe dieses Problem gesehen, wenn ich in ein Dateisystem schreibe, das die Zeiten nicht (richtig) handhabt - ich denke, SMB-Freigaben oder FAT oder so.

Was ist Ihr Zieldateisystem?

— David Wolever
quelle

Ich bin auf einem Mac und synchronisiere mit Linux (einer Slicehost-Maschine).

— Dreeves

Ah, seltsam ... Da Sie rsync auf dem Mac verwenden, sollte ich Sie warnen: Es werden nicht alle OS X-Dateiattribute ordnungsgemäß beibehalten, sodass schlimme Dinge passieren können. Siehe z. B.: Blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful

— David Wolever

Sie können jedoch die neueste Version von MacPorts ( sudo port install rsync) verwenden, da diese weniger kaputt geht. Um dies zu überprüfen rsync --version:: rsync Version 3.0.5 Protokoll Version 30 ... Anhängen, ACLs, Xattrs, Iconv, Symtimes, Dateiflaggen ... (ACLs und Xattrs sind die wichtigsten)

— David Wolever

1

rsync auf Macintosh setzt in der Tat alle Dateiattribute und tut dies schon seit einiger Zeit. Bitte beachten Sie, dass die URL, die auf "Bad Things könnte passieren" verweist, auf 2006 datiert ist!

— tgunr

2

Antworten sollten wirklich keine Fragen enthalten. Dies wäre als Kommentar besser geeignet.

— Brian

0

Es kann sein, dass Sie für einige Dateien keine Berechtigungen haben. Versuchen Sie in einem Administratorkonto "sudo rsync -av". Alternativ können Sie das Root-Konto aktivieren und sich als root anmelden. Das sollte es Ihnen ermöglichen, Ihr System vollständig abzuspritzen und Ihren Rsync brutal zu erzwingen! ;-) Ich bin mir nicht sicher, ob die oben genannten --extended-Attribute helfen werden, aber ich habe sie auch reingeworfen, nur aus gutem Grund.

— Kapitän
quelle

0

Dies geschah mir auf einer Partition vom Typ xfs (rw,relatime,seclabel,attr2,inode64,noquota), in der die Verzeichnisse einem anderen Benutzer in einer Gruppe gehörten, in der wir beide Mitglieder waren. Die Gruppenmitgliedschaft wurde bereits vor der Anmeldung festgelegt, und die gesamte Verzeichnisstruktur war für Gruppen beschreibbar. Ich hatte manuell ausgeführt sudo chown -R otheruser.group directoryund dies sudo chmod -R g+rw directoryzu bestätigen.

Ich habe immer noch keine Ahnung, warum es ursprünglich nicht funktioniert hat, aber ich habe das Eigentum übernommen, indem ich es sudo chown -R myuser.group directorybehoben habe. Vielleicht im Zusammenhang mit SELinux?

— Sam Brightman
quelle

Auf der Manpage wird die UID der App angegeben. muss mit der UID der Datei übereinstimmen utime(), damit es funktioniert. Sie können auch als root ausgeführt werden und dies tun. Wenn die UID der Datei jedoch unterschiedlich ist, können Sie die Uhrzeit nicht auf "jetzt" ändern.

— Alexis Wilke

Können Sie auf eine solche Manpage verlinken? Keiner von mir erwähnt utime().

— Sam Brightman

1

linux.die.net/man/2/utime Der entsprechende Absatz: "Das Ändern von Zeitstempeln ist zulässig, wenn: entweder der Prozess über entsprechende Berechtigungen verfügt oder die effektive Benutzer-ID der Benutzer-ID der Datei entspricht oder die Zeiten NULL sind und der Prozess hat Schreibberechtigung für die Datei. "

— Alexis Wilke

0

Dieser Fehler wird möglicherweise auch angezeigt, wenn Sie den rsync-Prozess für Dateien ausführen, die in der Quelle oder im Ziel nicht kürzlich geändert wurden, da die Zeit für die kürzlich geänderten Dateien nicht festgelegt werden kann.

— Gurdeep Singh
quelle