Błąd rsync: nie można ustawić czasów w „/ foo / bar”: Operacja niedozwolona

194

Dostaję mylący błąd z rsync i początkowe rzeczy, które znajduję podczas wyszukiwania w sieci (a także wszystkie zwykłe chmod'ing) nie rozwiązują go:

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]

Wygląda na to, że działa pomimo tego błędu, ale dobrze byłoby się go pozbyć.

rsync file-transfer

— dreeves
źródło

nie, tylko zwykły katalog, o ile wiem.

— dreeves

Właśnie napotkałem podobny problem, chociaż mój kod błędu to 22: rsync: nie udało się ustawić czasu na ... Nieprawidłowy argument (22). Po kilku sprawdzeniach okazało się, że moje pliki zostały opatrzone datą ostatniej modyfikacji w 1956 roku! Rozwiązanie: dotknij wszystkich plików, problem rozwiązany. :) „znajdź. -print0 | xargs -0 touch”

— KIAaze

Uważam, że jeśli skonfigurowałeś również zadanie cron do tego samego miejsca docelowego, ten błąd się pojawi. Zmiana czasu pracy crona (crontab) pomoże obejść ten problem. W moim przypadku ten błąd pojawia się tylko wtedy, gdy wykonuję ręczne rysnc, jeśli mam również skonfigurowane zadanie cron.

— NelsonGon

286

Jeśli /foo/barjest w systemie plików NFS (lub ewentualnie w systemie plików FUSE), może to być problem.

Tak czy inaczej, dodanie -O/ --omit-dir-timesdo linii poleceń pozwoli uniknąć próby ustawienia czasów modyfikacji w katalogach.

— Jon Bright
źródło

8

Zabawne jest to, że synchronizuję ext3 z ext3, oba systemy operacyjne są linuxowe. Nigdy wcześniej nie musiałem używać tego przełącznika. -O zrobiłem lewę, ale szkoda, że nie musiałem jej używać.

— d -_- b

3

Dzięki! Okazuje się, że niektóre hosty VPS (np. Xlshosting.nl) używają tego wewnętrznie, co może powodować problemy z rsync.

— Frederik

2

Mam ten sam problem z synchronizacją z Linux ext4 na Linux ext4: „nie można ustawić czasów: operacja niedozwolona” dla dowiązań symbolicznych , a nie katalogów. -Ooczywiście nie pomaga. Nie zdarzało się to, gdy moją partycją kopii zapasowej był ext3 zamiast ext4.

— Marius Gedminas,

10

Używałem rsync -avc i dodanie -O nie pomogło. Przeczytałem wtedy, że -a jest ekwiwalentem -rlptgoD, który obejmuje -t, które, jak sądzę, zastępuje -O. Więc dla mnie poprawką było użycie opcji -rlpgoDvc

— dlink

3

@dlink możesz dodać, --no-taby usunąć domyślną opcję.

— Noam Nelke,

86

Problem prawdopodobnie wynika z faktu, że / foo / bar nie jest własnością procesu pisania w zdalnym systemie darwin (OS X). Rozwiązaniem tego problemu jest ustawienie odpowiedniego właściciela na zdalnej stronie.

Ponieważ głosowano na tę odpowiedź, a zatem mam nadzieję, że była dla kogoś przydatna, rozszerzam ją, aby była jaśniejsza.

Powodem tego jest to, że rsync prawdopodobnie próbuje ustawić dowolny czas modyfikacji (mtime) podczas kopiowania plików.

Aby wykonać tę utime()funkcję systemową darwina, wymagane jest, aby efektywny identyfikator procesu pisania był taki sam jak identyfikator użytkownika pliku lub identyfikator superużytkownika, patrz strona opengroup utime . Sprawdź tę dyskusję na liście adresowej rsync jako odniesienie.

— anddam
źródło

10

To samo w systemie Linux (w moim przypadku Debian Squeeze) ... Jeśli nie jestem właścicielem katalogu docelowego, rsync wyświetla komunikat o błędzie „nie udało się ustawić czasów”. (Posiadanie uprawnienia do zapisu w katalogu nie wystarczy.)

— ddekany

1

Utknąłem w tym samym numerze. Aż do zamontowania NTFS z uid = user.

— gavenkoa

3

Ten błąd zniknął, gdy zmieniłem właściciela katalogu, na który próbowałem wpłynąć (na serwerze zdalnym), używając komendy rsync na tego samego użytkownika, który próbuje zalogować się za pomocą rsync na moim lokalnym skrypcie Bash. Innymi słowy: próbowałem pisać /remote/path/to/foo/barna zdalnym serwerze za pomocą tego polecenia: rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ user1@1.2.3.4:/remote/path/to/foo/bar otrzymałem te same komunikaty o błędach, które user1/remoe/path/to/foo/bar$ chown -R user1 /remote/path/to/foo/bar

— zniknęły,

1

Jeśli udostępniasz swoje pliki innym użytkownikom w grupie, na przykład używasz lepkiego klucza, zmiana właściciela nie jest tak naprawdę rozwiązaniem. Nie używamy -t i nie dodajemy -O, aby zapobiec temu ostrzeżeniu.

— R. van Twisk

1

Czy możesz rozwinąć odpowiedź, aby opracować dalej, jeśli użytkownik należy do grupy, która jest właścicielem pliku / katalogu, jeśli to powinno LUB nie powinno działać?

— Elijah Lynn,

4

Ponieważ @ racl101 skomentował odpowiedź, problem może być związany z właścicielem folderu . Polecenie rsync powinno być wykonane przez tego samego użytkownika, co właściciel folderu. Jeśli to nie to samo, możesz to zmienić.

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

— Lud Akell
źródło

2

Problem w moim przypadku polegał na tym, że „punkt montowania odbiornika” został nieprawidłowo zamontowany. Był w trybie tylko do odczytu (z jakiegoś dziwnego powodu). Wyglądało na to, że rsync kopiuje pliki, ale tak nie było. Sprawdziłem plik fstab i zmieniłem opcje montowania na domyślne, ponownie zamontowałem system plików i uruchom ponownie rsync. Wszystko w porządku.

— ripah
źródło

2

Miałem ten sam problem. Dla mnie rozwiązaniem jest usunięcie pliku zdalnego i rsyncutworzenie go ponownie.

— shintaroid
źródło

0

Widziałem ten problem, gdy piszę do systemu plików, który nie (właściwie) radzi sobie z czasami - myślę, że udziały SMB, FAT lub coś takiego.

Jaki jest twój docelowy system plików?

— David Wolever
źródło

Jestem na komputerze Mac, synchronizuję rsync'ing z linuksem (maszyna do hostowania plasterków).

— dreeves

Ach, dziwne ... Ponieważ używasz rsync na Macu, powinienem cię ostrzec: nie zachowuje właściwie wszystkich atrybutów pliku OS X, więc mogą się zdarzyć Bad Things. Patrz np .: blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful

— David Wolever

Możesz jednak użyć najnowszej wersji MacPorts ( sudo port install rsync), a to zepsuje mniej. Aby to sprawdzić rsync --version:: rsync wersja 3.0.5 protokół wersja 30 ... dopisz, listy ACL, xattrs, iconv, symtime, flagi plików ... (ACL i xattrs są najważniejsze)

— David Wolever

1

rsync na Macintoshu rzeczywiście ustawia wszystkie atrybuty plików i robi to już od dłuższego czasu, pamiętaj, że URL z odnośnikiem „Mogły się zdarzyć złe rzeczy” jest datowany na 2006 rok!

— tgunr

2

Odpowiedzi naprawdę nie powinny zawierać pytań. Byłoby to bardziej odpowiednie jako komentarz.

— Brian

0

Możliwe, że nie masz uprawnień do niektórych plików. Z konta administratora spróbuj „sudo rsync -av” Alternatywnie włącz konto roota i zaloguj się jako root. To powinno pozwolić ci całkowicie przepłukać system i brutalnie wymusić rsync! ;-) Nie jestem pewien, czy wyżej wymienione atrybuty pomogą, ale wrzuciłem to również dla pewności.

— kapitan
źródło

0

Zdarzyło mi się to na partycji typu xfs (rw,relatime,seclabel,attr2,inode64,noquota), w której katalogi były własnością innego użytkownika w grupie, której oboje byliśmy członkami. Członkostwo w grupie zostało już ustanowione przed zalogowaniem, a cała struktura katalogów była możliwa do zapisu przez grupę. Musiałem uruchomić ręcznie sudo chown -R otheruser.group directoryi sudo chmod -R g+rw directoryto potwierdzić.

Nadal nie mam pojęcia, dlaczego pierwotnie nie działało, ale przejęcie własności z sudo chown -R myuser.group directorynaprawione. Być może związane z SELinux?

— Sam Brightman
źródło

Strona podręcznika podaje identyfikator UID aplikacji. musi pasować do UID pliku, utime()aby działał. Możesz także uruchomić jako root i zrób to. Ale jeśli identyfikator UID pliku jest inny, nie pozwalają zmienić czasu na nic innego niż „teraz”.

— Alexis Wilke

Czy możesz link do takiej strony podręcznika? Żadna z moich wzmianek utime().

— Sam Brightman,

1

linux.die.net/man/2/utime Odpowiedni akapit: „Zmiana znaczników czasu jest dozwolona, gdy: albo proces ma odpowiednie uprawnienia, albo efektywny identyfikator użytkownika jest równy identyfikatorowi pliku lub czasy są równe NULL, a proces ma uprawnienia do zapisu dla pliku. ”

— Alexis Wilke

0

Ten błąd może również wyskakować, jeśli uruchomisz proces rsync dla plików, które nie zostały ostatnio zmodyfikowane w źródłowym lub docelowym ... ponieważ nie można ustawić czasu dla ostatnio zmodyfikowanych plików.

— Gurdeep Singh
źródło