Reputation: 31
I use a simple dockerfile from alpine with openssh and rsync installed. Ssh users are chrooted to their home directory and rsync and bash executable as well as chown, chmod etc. and their library are copied to the user directory so that rsync can be executed through ssh.
When I use rsync with -p options (included in -a) :
rsync -a -e 'ssh -p 2222' /home/user/Pictures/ localhost:/backups/071120
I get an error :
rsync: failed to set permissions on "/backups/071120/.Screenshot from 2019-12-26 13-47-24.png.NKoiaj": No such file or directory (2) The
files are copied but obviously the permissions are not set correctly.
I tried to change permission using ssh and everything works as expected so it should not a be a folder permission issue. And then I tried to use a ubuntu base image and it works as expected, so there is something in the alpine base image that prevent rsync to change permission.
Any idea of what it could be ?
Upvotes: 3
Views: 1769
Reputation: 5344
I don't know the cause of this problem, but I see it also in alpine. I ran with the same rsyncd.conf
, but in a debian container, and it worked as expected.
Upvotes: 1
Reputation: 1326
I had a similar issue working with rsync on alpine-based image.
Solution should be to disable the chroot
setting on the rsyncd.conf
file by specifying no at the following line:
use chroot = no
As per documentation ( https://download.samba.org/pub/rsync/rsyncd.conf.html ) setting the option to yes could complicate the preservation of users and groups by name
use chroot
If "use chroot" is true, the rsync daemon will chroot to the "path" before starting the file transfer with the client. This has the advantage of extra protection against possible implementation security holes, but it has the disadvantages of requiring super-user privileges, of not being able to follow symbolic links that are either absolute or outside of the new root path, and of complicating the preservation of users and groups by name (see below).
Upvotes: 3