rsync nie zachowuje własności katalogu nawet z opcją -a

Używam tego wywołania rsync do utworzenia kopii zapasowej mojego katalogu domowego:

rsync -aARrx --info= --force --delete --info=progress2 -F "$USER_HOME" "$BACKUP_MNTPOINT"

Strona man rsync mówi, że -a oznacza -g i -o (między innymi przełącznikami), co powinno zachować własność. Zauważyłem jednak, że jeśli katalog nie istnieje $BACKUP_MNTPOINT/$USER_HOME, jest on tworzony z własnością root: root zamiast z poprawnej. (Dzieje się tak tylko w przypadku katalogów bezpośrednio pod $BACKUP_MNTPOINT/$USER_HOME). Dlaczego?

$BACKUP_MNTPOINTjest dyskiem montowanym lokalnie. $BACKUP_MNTPOINT/$USER_HOMEma odpowiednią własność i uprawnienia. Ani się $USER_HOMEnie $BACKUP_MNTPOINTkończy ukośnikiem.

Zarówno źródłowy, jak i docelowy system plików to XFS, a uruchomienie mkdir $BACKUP_MNTPOINT/$USER_HOMEtworzy katalog z oczekiwaną własnością.

— kralyk
źródło

Czym jest system plików $BACKUP_MNTPOINTi przy jakich opcjach jest montowany? Czy dzieje się tak tylko w przypadku katalogu macierzystego ( $BACKUP_MNTPOINT/$USER_HOME) lub wszystkich utworzonych katalogów? Zrób $BACKUP_MNTPOINTi $USER_HOMEzakończ z /?

— terdon

Używam XFS zarówno dla /homedysku zapasowego, jak i dla niego. Jak dotąd myślę, że stało się to tylko w przypadku katalogów nadrzędnych. Ani się $BACKUP_MNTPOINTnie $USER_HOMEkończy ukośnikiem. EDYCJA: Mogę potwierdzić, że teraz dzieje się to tylko z katalogami poniżej$BACKUP_MNTPOINT/$USER_HOME

— kralyk

Czy $BACKUP_MNTPOINT/$USER_HOMEma odpowiednie uprawnienia, ale nie ma w nim żadnych podkatalogów? Proszę edytować swoje pytanie i dodać te szczegóły. Wyjaśnij również, czy mkdir $BACKUP_MNTPOINT/$USER_HOME/footworzy katalog należący do użytkownika, jeśli robisz to ręcznie.

— terdon

Tak, mkdir $BACKUP_MNTPOINT/$USER_HOME/footworzy katalog z własnością użytkownika.

— kralyk

Byłoby naprawdę miło zobaczyć odpowiednie informacje z strace(jak podano w pseudo-odpowiedzi).

— Pavel Šimerda

Odpowiedzi:

Miałem podobny problem podczas rsynctworzenia kopii zapasowej systemu na serwerze. Użyłem:

rsync -aAXSHPr \
-e ssh \
--rsync-path="sudo /usr/bin/rsync/" \
--numeric-ids \
--delete \
--progress \
--exclude-from="/path/to/file/that/lists/excluded/folders.txt" \
--include-from="/path/to/file/that/lists/included/folders.txt" \
/ USER@SERVER:/path/to/folder/where/backup/should/go/

Rozwiązaniem jest to, że tak naprawdę nie ma problemu. Podejrzewam, że przerwałeś rsyncproces, gdy zobaczyłeś, że tworzy foldery z nieprawidłowymi ustawieniami uprawnień. Najważniejsze jest to, że rsyncustawia uprawnienia do folderu nadrzędnego dopiero po zakończeniu synchronizacji wszystkich jego podfolderów i plików.

— lord.garbage
źródło

Wow, nie przyszło mi to do głowy, ładnie zauważone, dzięki.

— kralyk

Być może uruchom rsync przez strace / truss i sprawdź, czy otrzymasz błąd z syscall chown (), a także, aby potwierdzić, że chown () ma poprawną ścieżkę i identyfikator UID / GID.

— Jez
źródło

Dobry komentarz, ale nie odpowiedź.

— Pavel Šimerda