rsync - mkstemp failed: Permission denied (13)

Question

Mam następujący setup okresowo rsync pliki z serwera A na serwer B. Serwer B został uruchomiony demon rsync z następującej konfiguracji:

read only = false 
use chroot = false 
max connections = 4 
syslog facility = local5 
log file = /var/adm/rsyncd.log 
munge symlinks = false 
secrets file = /etc/rsyncd.secrets 
numeric ids = false 
transfer logging = true 
log format = %h %o %f %l %b 


[BACKUP] 
     path = /path/to/archive 
     auth users = someuser 

z serwera AI wyda następującą komendę:

rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ someuser@192.168.100.100::BACKUP 

Katalog BACKUP jest w pełni do odczytu/zapisu/wykonywania dla wszystkich. Kiedy uruchomić polecenie rsync z serwera A, widzę:

afile.txt 
     989 100% 2.60kB/s 0:00:00 (xfer#78, to-check=0/79) 

dla każdego i everyfile w katalogu pragnę kopii zapasowej. To nie kiedy się do zapisu plików tmp:

rsync: mkstemp "/.afile.txt.PZQvTe" (in BACKUP) failed: Permission denied (13) 

Godziny googlowania później i nadal nie mogę rozwiązać to, co wydaje się być bardzo prosta kwestia zgody. Rada? Z góry dziękuję.

Dodatkowe informacje

Właśnie zauważyłem następujące występuje na początku procesu:

rsync: failed to set permissions on "/." (in BACKUP): Permission denied (13) 

Próbuje ustawić uprawnienie „/”?

Edit

jestem zalogowany jako użytkownik - someuser. Mój katalog docelowy ma pełne uprawnienia do odczytu/zapisu/uruchamiania dla wszystkich, łącznie z jego zawartością. Ponadto katalog docelowy należy do someuser i do grupy użytkownika.

Kontynuacja

Znalazłem za pomocą SSH rozwiązuje ten

Answer 1

Upewnij się, że użytkownik jesteś rsync'd się na zdalnym komputerze ma dostęp do zapisu zawartości folderu oraz sam folder, ponieważ rsync próbował zaktualizować czas modyfikacji w samym folderze.

Answer 2

Mimo że to działa, ostatnio miałem podobne spotkanie i żadne wyszukiwanie SO lub Google nie było pomocne, ponieważ wszystkie zajmowały się podstawowymi problemami z uprawnieniami, a poniższe rozwiązanie jest nieco wyłączonym ustawieniem, którego nie chcesz nawet pomyśl, aby sprawdzić w większości sytuacji.

Jedna rzecz, dla której za zezwoleniem odmówiono, że ostatnio znalazłem problem z rsync, gdzie uprawnienia były dokładnie takie same na obu serwerach, w tym właściciela i grupy, ale transfery rsync działały w jedną stronę na jednym serwerze, ale nie w inny sposób.

Okazało się, że serwer z problemami, od których otrzymałem odmowę uprawnień, miał włączoną funkcję SELinux, która z kolei nadpisuje uprawnienia POSIX do plików/folderów. Tak więc pomimo tego, że folder, o którym mowa, mógł mieć 777 przy uruchomieniu roota, uruchomiono komendę SELinux, która z kolei nadpisałaby te uprawnienia, które spowodowały "odmowę zgody" - z rsync.

Możesz uruchomić polecenie getenforce, aby sprawdzić, czy włączono SELinux na komputerze.

W mojej sytuacji skończyłem po prostu całkowicie wyłączając SELINUX, ponieważ nie był potrzebny i został wyłączony na serwerze, który działał poprawnie i tylko powodował problemy z włączeniem. Aby wyłączyć, otwórz /etc/selinux/config i ustaw SELINUX=disabled. Aby tymczasowo wyłączyć, możesz uruchomić komendę setenforce 0, która ustawi SELinux na stan permissive zamiast stanu enforcing, co spowoduje, że wydrukuje ostrzeżenia zamiast wymuszać.

Answer 3

Demon Rsync domyślnie używa nobody/nogroup dla wszystkich modułów, jeśli działa pod użytkownikiem root. Musisz więc zdefiniować parametry uid i gid dla wybranego użytkownika lub ustawić je jako root/root.

Answer 4

Miałem podobny problem, ale w moim przypadku było tak dlatego, że pamięć ma tylko SFTP, bez ssh i demonów rsync. Nie mogłem nic zmienić, bcs ten serwer został dostarczony przez mojego klienta.

rsync nie mógł zmienić daty i godziny pliku, niektóre inne narzędzia (np. Csync) pokazały mi inne błędy: "Nie można utworzyć pliku tymczasowego wykrytego przekręcenia". Jeśli masz dostęp do serwera pamięci - po prostu zainstaluj openssh-server lub uruchom rsync jako demon.

W moim przypadku - nie mogłem tego zrobić i rozwiązanie było: lftp. Wykorzystanie lftp za synchronizacja jest poniżej:

lftp -c "open -u login,password sftp://sft.domain.tld/; mirror -c --verbose=9 -e -R -L /srs/folder /rem/folder" 

/src/folder - to folder na moim PC/rem/folder - jest sftp: //sft.domain.tld/rem/folder.

można znaleźć Mans przez link lftp.yar.ru/lftp-man.html

Answer 5

metę w dostępie korzeń ssh chould rozwiązać ten problem

lub chmod 0777 /dir/to/be/backedup/

lub chown username:user /dir/to/be/backedup/

Answer 6

Windows: sprawdź uprawnienia folderów docelowych. Przejmij własność, jeśli musisz przekazać prawa do konta, na którym działa usługa rsync.

Answer 7

Może to nie odpowiadać wszystkim, ponieważ nie zachowuje oryginalnych uprawnień do plików, ale w moim przypadku nie było to ważne i rozwiązało problem. rsync posiada opcję --chmod:

--chmod Ta opcja informuje rsync, aby zastosować jeden lub więcej oddzielonych przecinkami ciągi lqchmodrq do zgody plików w transferze. Uzyskana wartość jest traktowana tak, jakby była uprawnieniami dostarczonymi przez stronę wysyłającą dla strony , co oznacza, że ​​opcja ta może wydaje się nie mieć wpływu na istniejące pliki, jeśli opcja -perms nie jest włączona.

Wymusza to uprawnienia do tego, co chcesz na wszystkich plikach/katalogach. Na przykład:

rsync -av --chmod=Du+rwx SRC DST 

dodałby odczyt, zapis i wykonanie dla użytkownika do wszystkich przesłanych katalogów.

Answer 8

Wyobrażam sobie, że wspólny błąd, który nie jest obecnie wspomniany powyżej, próbuje zapisać się do przestrzeni montażowej (np. /media/drivename), gdy partycja nie jest zamontowana. To również spowoduje ten błąd.

Jeśli jest to zaszyfrowany dysk ustawiony na automatyczne montowanie, ale nie działa, może to być problem z automatycznym odblokowaniem zaszyfrowanej partycji przed próbą zapisania w miejscu, w którym ma zostać zamontowany.

Answer 9

Miałem ten sam błąd podczas synchronizowania plików wewnątrz kontenera Docker, a miejscem docelowym był wolumin zamontowany (Docker for mac), uruchamiam rsync przez su-exec <user>. Udało mi się go rozwiązać, uruchamiając rsync jako root z flagami -og (zachowaj właściciela i grupę dla plików docelowych).

Nadal nie jestem pewien, co spowodowało ten problem, uprawnienia do miejsca docelowego były OK (prowadzę chown -R <user> dla katalogu docelowego przed rsync), być może w jakiś sposób związane z wolnym systemem plików Docker for Mac.

Answer 10

Ten problem również napotykam i rozwiązuję go przez "zaptanie" użytkownika docelowego floder. Myślę, że jest ok dla chmod a + rwx.