78

I have the following setup to periodically rsync files from server A to server B. Server B has the rsync daemon running with the following configuration:

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

From server A I am issuing the following command:

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

BACKUP directory is fully read/write/execute to everyone. When I run the rsync command from server A, I see:

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

for each and everyfile in the directory I wish to backup. It fails when I get to writing tmp files:

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

Hours of googling later and I still can't resolve what seems to be a very simple permission issue. Advice? Thanks in advance.

Additional Information

I just noticed the following occurs at the beginning of the process:

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

Is it trying to set permission on "/"?

Edit

I am logged in as the user - someuser. My destination directory has full read/write/execute permission for everyone, including it's contents. In addition, the destination directory is owned by someuser and in someuser's group.

Follow up

I've found using SSH solves this

  • Is this configuration had worked one time ? – Gilles Quénot Jun 14 '12 at 19:24
  • 1
    @sputnick: I use this same configuration to PULL via rsync but this process is a PUSH. So to answer your question, I have not used this configuration in this kind of setup. –  Jun 14 '12 at 19:26
  • 3
    Using SSH is a workaround, not really a solution or understanding of the permissions issue here. I'm having a similar problema and using SSH is not an option for me :/ – Jorge Orpinel Pérez Oct 07 '14 at 17:57
  • 1
    Error (13) is a folder permissions issue. This is nicely explained here http://superuser.com/questions/398146/rsync-permission-denied-backing-up-a-remote-directory-to-my-local-machine – ajmccall Jul 02 '15 at 08:12

18 Answers18

37

Make sure the user you're rsync'd into on the remote machine has write access to the contents of the folder AND the folder itself, as rsync tried to update the modification time on the folder itself.

Mauvis Ledford
  • 40,827
  • 17
  • 81
  • 86
  • Thank you for your reply. I've ensured I am the same user with permission, ownership and group settings. Please see my edit. –  Jun 14 '12 at 22:33
  • 3
    Thanks. I had this problem on a Synology DiskStation and it solved the problem. It is irrelevant if the owner is an administrator or not, the folder must be owned by the rsync job user. – M46 Mar 11 '20 at 11:25
  • 1
    Indeed, thanks @mauvis-ledford , in this case the remote folder was root:root instead of someuser:someuser ( and we connected using someuser ... ) – Ramon Fincken May 27 '22 at 07:46
20

Even though you got this working, I recently had a similar encounter and no SO or Google searching was of any help as they all dealt with basic permission issues wheres the solution below is somewhat of an off setting that you wouldn't even think to check in most situations.

One thing to check for with permission denied that I recently found having issues with rsync myself where permissions were exactly the same on both servers including the owner and group but rsync transfers worked one way on one server but not the other way.

It turned out the server with problems that I was getting permission denied from had SELinux enabled which in turn overrides POSIX permissions on files/folders. So even though the folder in question could have been 777 with root running, the command SELinux was enabled and would in turn overwrite those permissions which produced a "permission denied"-error from rsync.

You can run the command getenforce to see if SELinux is enabled on the machine.

In my situation I ended up just disabling SELINUX completely because it wasn't needed and already disabled on the server that was working fine and just caused problems being enabled. To disable, open /etc/selinux/config and set SELINUX=disabled. To temporarily disable you can run the command setenforce 0 which will set SELinux into a permissive state rather then enforcing state which causes it to print warnings instead of enforcing.

Jeff Wilbert
  • 4,400
  • 1
  • 20
  • 35
  • For me it was SELinux! Thanks! – Christian Ulbrich Apr 24 '18 at 22:12
  • If I get "command not found" for getenforce does this mean that my server does not have SELinux? – Marecky Nov 07 '20 at 01:11
  • @Marecky Not necessarily, depending how you are running the command and/or how your $PATH variable is setup could result in command not found. Try running `/usr/sbin/getenforce` which is the full path where `getenforce` usually is. – Jeff Wilbert Nov 12 '20 at 01:23
  • @Marecky You can also do a search of the installed packages `yum list installed | grep selinux` or `apt list --installed | grep selinux` depending on distro. Note that if libselinux is found that doesn't mean it's enabled and/or active on the server. Another alternative to selinux to check for is AppArmor `apparmor_status`. – Jeff Wilbert Nov 12 '20 at 01:32
17

Rsync daemon by default uses nobody/nogroup for all modules if it is running under root user. So you either need to define params uid and gid to the user you want, or set them to root/root.

Marki555
  • 6,434
  • 3
  • 37
  • 59
  • 2
    This answer really helped me. I had to set up the rsync daemon since rsync over ssh was too slow (plus I would have to allow root over ssh, which is no good). But I kept getting `failed to set times on "/." (in linuxbackup): Operation not permitted (1)` even though the remote daemon was already running as root. Changing `uid` and `gid` to `root` in `rsyncd.conf` fixed that – user10607 Sep 11 '16 at 11:09
  • 1
    This proved to be the fix for me. I thought it was SELinux, but after `chcon` didn't fix it... My rsyncd.conf had `uid = %RSYNC_USER_NAME%` and `gid = *`, which seems like it should work as long as the source client is running with the same ids as the dest directory. Setting both explicitly to `root` fixed it. – pyansharp Jul 27 '22 at 17:55
15

I encountered the same problem and solved it by chown the user of the destination folder. The current user does not have the permission to read, write and execute the destination folder files. Try adding the permission by chmod a+rwx <folder/file name>.

trent
  • 25,033
  • 7
  • 51
  • 90
hao
  • 151
  • 1
  • 2
  • it's better to write example also. – Gahan Jun 30 '17 at 06:02
  • 1
    it's apparently important to own the entire path hierarchy. Being the owner of the destination folder is not enough. You have to own the parent directories too. I'm a bit suprised but it worked only if I'm the owner of all parents.... – Altimac Nov 30 '20 at 17:50
7

This might not suit everyone since it does not preserve the original file permissions but in my case it was not important and it solved the problem for me. rsync has an option --chmod:

--chmod This option tells rsync to apply one or more comma-separated lqchmodrq strings to the permission of the files in the transfer. The resulting value is treated as though it was the permissions that the sending side supplied for the file, which means that this option can seem to have no effect on existing files if --perms is not enabled.

This forces the permissions to be what you want on all files/directories. For example:

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

would add Read, Write and Execute for the user to all transferred directories.

Zitrax
  • 19,036
  • 20
  • 88
  • 110
  • Same for me backuping a Synology NAS to a distant server using rsync over SSH. – Simon Jul 26 '17 at 13:56
  • Synology-NAS: I had to add `--rsync-path=/bin/rsync` to rsync to get rid of the "permission denied". – fdelia May 08 '18 at 13:38
  • As @fdelia suggesting adding `--rsync-path=/usr/bin/rsync` to the rsync command I now have `rsync -rvp --rsync-path=/usr/bin/rsync $SOURCE $DESTINATION` solved my problem magically. But I don't know why and thats a bit frustrating. – Jakob Ojvind Nielsen Dec 11 '21 at 13:05
3

I had a similar issue, but in my case it was because storage has only SFTP, without ssh or rsync daemons on it. I could not change anything, bcs this server was provided by my customer.

rsync could not change the date and time for the file, some other utilites (like csync) showed me other errors: "Unable to create temporary file Clock skew detected". If you have access to the storage-server - just install openssh-server or launch rsync as a daemon here.

In my case - I could not do this and solution was: lftp. lftp's usage for syncronization is below:

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

/src/folder - is the folder on my PC, /rem/folder - is sftp://sft.domain.tld/rem/folder.

you may find mans by the link lftp.yar.ru/lftp-man.html

bolD
  • 141
  • 1
  • 4
2

Windows: Check permissions of destination folders. Take ownership if you must to give rights to the account running the rsync service.

Shield Edge Technologies
  • 31
  • 1
2

I had the same issue in case of CentOS 7. I went through lot of articles ,forums but couldnt find out the solution. The problem was with SElinux. Disabling SElinux at the server end worked. Check SELinux status at the server end (from where you are pulling data using rysnc) Commands to check SELinux status and disable it

$getenforce

Enforcing ## this means SElinux is enabled

$setenforce 0

$getenforce

Permissive

Now try running rsync command at the client end ,it worked for me. All the best!

aastha
  • 41
  • 3
1

I have Centos 7 server with rsyncd on board: /etc/rsyncd.conf

[files]
path = /files

By default selinux blocks access for rsyncd to /files folder

# this sets needed context to my /files folder
sudo semanage fcontext -a -t rsync_data_t '/files(/.*)?'
sudo restorecon -Rv '/files'
# sets needed booleans
sudo setsebool -P rsync_client 1

Disabling selinux is an easy but not a good solution

shmakovpn
  • 751
  • 9
  • 10
  • 1
    Thanks so much, you finally unblocked my installation of rsync! I totally agree with you, SELinux exists for a reason, it's a pity so many people just disable it instead of learning how it works. – Paul Podgorsek Apr 25 '20 at 17:11
1

I had the same issue, so I first SSH into the server to confirm that I able to log in to the server by using the command:

ssh -i /Users/Desktop/mypemfile.pem user@ec2.compute-1.amazonaws.com

Then in New Terminal

I copied a small file to the server by using SCP, to make sure I am able to make a connection:

scp -i /Users/Desktop/mypemfile.pem /Users/Desktop/test.file user@ec2.compute-1.amazonaws.com:/home/user/test/

Then In the same new terminal, I tried running rsync:

rsync -avz -e "ssh -i /Users/Desktop/mypemfile.pem" /Users/Desktop/backup/image.img.gz user@ec2.compute-1.amazonaws.com:
Lakshay
  • 180
  • 1
  • 10
1

If you're on a Raspberry pi or other Unix systems with sudo you need to tell the remote machine where rsync and sudo programs are located.

I put in the full path to be safe.

Here's my example:

rsync --stats -paogtrh --progress --omit-dir-times --delete --rsync-path='/usr/bin/sudo /usr/bin/rsync'  /mnt/drive0/ pi@192.168.10.238:/mnt/drive0/
kylewelsby
  • 4,031
  • 2
  • 29
  • 35
Eric Kowalewski
  • 39
  • 6
0

I imagine a common error not currently mentioned above is trying to write to a mount space (e.g., /media/drivename) when the partition isn't mounted. That will produce this error as well.

If it's an encrypted drive set to auto-mount but doesn't, might be an issue of auto-unlocking the encrypted partition before attempting to write to the space where it is supposed to be mounted.

Wolf
  • 567
  • 7
  • 10
0

I had the same error while syncing files inside of a Docker container and the destination was a mounted volume (Docker for mac), I run rsync via su-exec <user>. I was able to resolve it by running rsync as root with -og flags (keep owner and group for destination files).

I'm still not sure what caused that issue, the destination permissions were OK (I run chown -R <user> for destination dir before rsync), perhaps somehow related to Docker for Mac slow filesystem.

Anders R. Bystrup
  • 15,729
  • 10
  • 59
  • 55
chingis
  • 1,514
  • 2
  • 19
  • 38
0

Take attention on -e ssh and jenkins@localhost: in next example:

rsync -r  -e ssh --chown=jenkins:admin --exclude .git --exclude Jenkinsfile --delete ./ jenkins@localhost:/home/admin/web/xxx/public

That helped me

P.S. Today, i realized that when you change (add) jenkins user to some group, permission will apply after slave (agent) restart. And my solution (-e ssh and jenkins@localhost:) need only when you can't restart agent/server.

RavinderSingh13
  • 130,504
  • 14
  • 57
  • 93
basil
  • 3,482
  • 2
  • 22
  • 20
0

Yet still another way to get this symptom: I was rsync'ing from a remote machine over ssh to a Linux box with an NTFS-3G (FUSE) filesystem. Originally the filesystem was mounted at boot time and thus owned by root, and I was getting this error message when I did an rsync push from the remote machine. Then, as the user to which the rsync is pushed, I did:

$ sudo umount /shared
$ mount /shared

and the error messages went away.

Blob
  • 146
  • 5
0

The group user name for the destination directory and sub directories should be same as per the user.

if the user is 'abc' then the destination directory should be lrwxrwxrwx 1 abc abc 34 Jul 18 14:05 Destination_directory

command chown abc:abc Destination_directory

gauraw tiwari
  • 11
-1

Surprisingly nobody have mentioned all powerful SUDO. Had the same problem and sudo fixed it

Rimski
  • 27
  • 3
  • 2
    "sudo" is not a fix unless you know for certain what the problem is. More often then not, blindly sudoing will cause more problems than it fixes. – CodeMouse92 Jul 08 '20 at 16:05
-4

run in root access ssh chould solve this problem

or chmod 0777 /dir/to/be/backedup/

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

yuli chika
  • 9,053
  • 20
  • 75
  • 122