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, 2015 at 1:36
  • @JeffSchaller Ah yes I forgot. Added.
    – tendays
    Sep 18, 2015 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, 2015 at 1:43

1 Answer 1


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.

  • 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, 2015 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, 2015 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, 2015 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .