Bug 11414 - rsync: chgrp "/.filename.5afK5X" (in dirdir) failed: Operation not permitted (1)
rsync: chgrp "/.filename.5afK5X" (in dirdir) failed: Operation not permitted (1)
Status: RESOLVED WORKSFORME
Product: rsync
Classification: Unclassified
Component: core
3.1.1
x64 Linux
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-27 08:54 UTC by Nguyen Si Nhan
Modified: 2017-11-08 08:44 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nguyen Si Nhan 2015-07-27 08:54:13 UTC
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
Comment 1 Nguyen Si Nhan 2015-07-27 09:27:09 UTC
When I add this line to rsyncd.conf it's ok:
fake super = yes
Comment 2 Michal Ruprich 2017-11-06 15:31:36 UTC
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?
Comment 3 Kevin Korb 2017-11-06 16:20:28 UTC
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.
Comment 4 Michal Ruprich 2017-11-07 08:11:33 UTC
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?
Comment 5 Michal Ruprich 2017-11-07 08:55:40 UTC
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.
Comment 6 Kevin Korb 2017-11-07 15:05:46 UTC
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.
Comment 7 Michal Ruprich 2017-11-08 08:44:28 UTC
Thank you Kevin. This makes sense.