Notice : With The configuration file below in version 3.0.6,it is working . ----------------------------------------------------------------------------- -My rsync's config (rsyncd.conf): ========================================== lock file = /var/run/rsync.lock log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid ignore errors= true uid = sfftp gid = sfftp reverse lookup = no [9tlocal] path=/sfarm/9tlocal/ uid = www gid = www auth users = 9tlocal secrets file = /etc/rsyncd.secrets read only = no log file = /var/log/rsyncd9tlocal.log ============================================ However I got a problem with rsync daemon on version 3.1.1: When I execute this cmd : rsync -avz --progress --delete /data/client/ 9tlocal@10.76.0.195::9tlocal It sync data to dir /sfarm/9tlocal/ but It show these error log: rsync -avz --progress --delete /data/client/ 9tlocal@10.76.0.195::9tlocal Password: sending incremental file list rsync: chgrp "/." (in 9tlocal) failed: Operation not permitted (1) rsync: failed to open "/syn_pre_update.log" (in 9tlocal), continuing: Permission denied (13) rsync: failed to open "/test" (in 9tlocal), continuing: Permission denied (13) ./ syn_pre_update.log 2,017 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=1/3) test 1,073,741,824 100% 63.80MB/s 0:00:16 (xfr#2, to-chk=0/3) rsync: chgrp "/.syn_pre_update.log.4kTDrH" (in 9tlocal) failed: Operation not permitted (1) rsync: chgrp "/.test.yVQDby" (in 9tlocal) failed: Operation not permitted (1) sent 1,044,817 bytes received 486 bytes 27,874.75 bytes/sec total size is 1,073,743,841 speedup is 1,027.21 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1] ls -al /data/client/ total 1048592 drwxr-xr-x 2 root root 4096 Th07 27 14:07 . drwxr-xr-x 3 root root 4096 Th07 27 11:17 .. -rw-r--r-- 1 root root 2017 Th07 27 14:07 syn_pre_update.log -rw-r--r-- 1 root root 1073741824 Th07 24 14:34 test ls -al /sfarm/9tlocal/ total 1048592 drwxr-xr-x 2 www www 4096 Th07 27 14:07 . drwxr-xr-x 5 root root 4096 Th07 27 11:25 .. -rw------- 1 www www 2017 Th07 27 14:58 syn_pre_update.log -rw------- 1 www www 1073741824 Th07 27 14:58 test =========================================================== Finally I re-run cmd with below option(replace option -a by -r )it's OK : rsync -rvz --progress --delete /data/client/ 9tlocal@10.76.0.195::9tlocal
When I add this line to rsyncd.conf it's ok: fake super = yes
I stumbled upon this bug and I have a question. I get the chgrp error even when running the daemon as root. #ps -aux | grep rsync root 18486 0.0 0.0 114696 568 ? Ss 09:41 0:00 rsync --daemon I have configured a module in /etc/rsyncd.conf like this: [my_data] comment = test dir for rsync path = /home/tester read only = no uid = tester gid = tester Now when I try to copy file 'data' to this module: # rsync -av data localhost::my_data sending incremental file list data rsync: chgrp "/.data.CFttwz" (in my_data) failed: Operation not permitted (1) sent 86 bytes received 117 bytes 406.00 bytes/sec total size is 0 speedup is 0.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1178) [sender=3.1.2] This doesn't happen with version 3.0.9. And I think that this should not happen. It works fine with the 'fake super' option set to 'yes' but the daemon runs under root and the fake super option says: "This allows the full attributes of a file to be stored without having to have the daemon actually running as root." From this description I would assume that you don't need the 'fake super' option to transfer all attributes when the daemon runs under root right?
Oops, I replied to this on the email list instead of the bugzilla. Sorry for the extra noise... It isn't running as root (it probably never should). It is launched as root. It is running as tester:tester just like you set it to.
I see. I never looked at the ps aux output during the transfer so all I saw was the user that launched the daemon. So I assume that the chgrp error that occurs without the fake super option is the correct behaviour and the previous version did this wrong?
There is one more thing that doesn't make sense to me. Even if the operation of changing the group fails, why doesn't rsync finish other things under the -a option. For instance the permissions of the original file are 0644 and if the chgrp error occurs, the destination permissions are just 0600. The user tester owns the destination file and it should be able to change the permissions.
There was a change made in 3.1.0... - Added a way for more than one group to be specified in the daemon's config file, including a way to specify that you want all of the specified user's groups without having to name them. Also changed the daemon to complain about an inability to set explicitly-specified uid/gid values, even when not run by a super-user. So, even if a user is in more than one group once you set the gid option the listed groups are all that user gets to be in now. I am not sure if the lack of permission setting is a bug or an rsyncd feature and I don't know if it is still the case in the current version. I don't really feel like setting up a test case to find out. IMO if you are running rsyncd without read only = yes and/or withe authentication you are mis-using rsyncd. If you want these things use rsync over ssh where you have decent authentication+security.
Thank you Kevin. This makes sense.