I am using rsync to backup some folders in my home directory to a remote server using the following commands:

rsync -Favz --inplace --delete --delete-excluded folder1 folder2 folder3 remote-server:/remote/path/

All files are owned by my user, both locally and remotely.

It works fine except with files that have mode r--r--r--, even though my user is the owner of those files and the parent directory.

This is what rsync reports for those files:

rsync: open "/remote/path/somefolder/somefile" failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.0]

As a temporary solution I am able to log on the remote machine (same user), delete the files and re-run rsync which will then create those files in those modes, however next time I run the script it will fail again.

Is there a way to have rsync overwrite non-writable files on the remote side (or delete them and create them again) or do I have to settle with first deleting them remotely and then running the backup script?

This question is quite similar to How to backup /etc/{,g}shadow files with 0000 permission? except that the latter talks about non-readable files and my question is about readable but non-writable files.

  • Please edit your post to include the error(s) you get from rsync with these "r--r--r--" mode files. – Jeff Schaller Sep 18 '15 at 1:36
  • @JeffSchaller Ah yes I forgot. Added. – tendays Sep 18 '15 at 1:39
  • I could not reproduce this error. What are the permissions of the directory containing these files? (Add the output of namei -mo somefolder/somepath if it isn't too private). – muru Sep 18 '15 at 1:43

This is side effect of --inplace option. This is more for disk to disk synchronizing not over the network. The other side effects, like leaving files in inconsistent state on transfer interruption can be problematic too. Try to synchronize without --inplace as rsync delta-transfer algorithm is already extreme efficient.

| improve this answer | |
  • Yep, now I can reproduce (partially) with --inplace. My rsync just says connection unexpectedly closed and error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0], though. – muru Sep 18 '15 at 1:58
  • @muru simplest scenario:` $ mkdir a b $ date > a/aa $ chmod 444 a/aa $ ls -l a/ total 4 -r--r--r--. 1 user user 33 09-18 04:06 aa $ rsync --inplace a/* b/ $ ls -l b/ total 4 -r--r--r--. 1 user user 33 09-18 04:07 aa $ chmod 744 a/aa $ date >> a/aa $ rsync --inplace a/* b/ rsync: open "/home/user/tmp/tmp/b/aa" failed: Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.0] $ ` – alcik Sep 18 '15 at 2:11
  • Yes! Removing --inplace fixes the problem. However it prevents resuming partially uploaded files (in case a transfer is interrupted, partially uploaded files will be saved in a .rsync-something file which is deleted next time I run the script. Big problem because my connection is slow). So I'll keep that option in and disable it just whenever a non-writable file changed, as it happens rarely enough. Thank you! – tendays Sep 21 '15 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.