2

I'm running ansible with the synchronize module, which underneath runs rsync. My problem is not ansible-related, as I took the rsync command from the debug output and ran it manually - still the same issue.

The command I ran is:

/usr/bin/rsync --delay-updates -F --rsync-path="sudo rsync" --compress --delete-after --archive "/local/path" "[email protected]:/remote/path" --chown=myuser:myuser

Whatever I try - I end up with the directory belonging to root:root.

I therefore now rsync successfully runs as root, so it should have all neccessary permissions. I also tried using --usermap=*:myuser --groupmap=*:myuser - nothing.

I added --chmod=750 - not being applied.

In the debug output (-vvvv), I can see my parameters again, but that's it.

No warning, no error, but also no later mention of anything containing "user", "group", "chown" etc... rsync is 3.1.1 on Debian 8.

Any help would be appreciated...

2 Answers 2

2

The chown system call (and, by extension, the chown and rsync --chown commands) may only be used by root. You're connecting to the remote system as the ansible user, so the remote system will not permit the operation. The rsync command recognizes that it's not running as root on the remote system, so it silently ignores the --chown option and others like it (e.g., --mapuser).

The rsync manual is not really explicit about this behavior, but if you specify the --super option as well, it will cause rsync on the remote system to assume it is running as root, even if it is not. This will allow it to attempt the chown operation, and to produce an error if or when it fails.

EDIT:

If you do manage to execute rsync on the remote system as root (e.g., using --rsync-path="sudo rsync"), you will still need to add a couple options for --chown to be usable. The manual states:

--chown=USER:GROUP
    This option forces all files to be owned by USER with group GROUP.
    This is a simpler interface than using --usermap and --groupmap
    directly, but it is implemented using those options internally, so
    you cannot mix them.

And here's what the manual says for --usermap and --groupmap:

--usermap=STRING, --groupmap=STRING
    ...
    For the --usermap option to have any effect, the -o (--owner)
    option must be used (or implied), and the receiver will need to
    be running as a super-user (see also the --fake-super option).
    For the --groupmap option to have any effect, the -g (--groups)
    option must be used (or implied), and the receiver will need to
    have permissions to set that group. 

In addition to using --rsync-path to run it under sudo, try adding the -o and -g options as well.

5
  • I read something like that too, but... via --rsync-path="sudo rsync", it actually runs as root, as I can see because the files are afterwards owned by root. Also, adding --super doesn't change anything - I tried that before.
    – xpac
    Oct 31, 2018 at 15:10
  • Your question doesn't make it clear that your invocation of rsync causes it to run as root on the remote system. That being the case, you probably need the -o and -g options as well; I've updated my answer to explain why. Oct 31, 2018 at 15:56
  • Yeah, it's only implicitely mentioned by the directory ending up belonging to root:root. I added the --rsync-path to the question, I removed it by error. I tried adding -o and -g, and also -p (although they should be included in --archive) - didn't help.
    – xpac
    Oct 31, 2018 at 16:09
  • My mistake, I missed that you had --archive specified. Perhaps the invocation under sudo is losing some options. Does the sudo log (not sure where it goes in Debian) show the correct options being applied? Oct 31, 2018 at 17:13
  • sudo wasn't the offender... it was partially me, and maybe it's also a bug.
    – xpac
    Nov 4, 2018 at 17:23
0

sudo wasn't the offender... it was partially me, and maybe it's also a bug/feature working differently than expected.

My ansible task added the source folder name to the destination path, which resulted in that path being created, and than the source folder being created inside that folder, effectively doubling the folder structure to /destination/path/source/source/...

--chmod is being applied to the second source folder, but not to the one created as part of the destination structure. Therefore, the top source belongs to root, but the second source belongs to the user it should belong too.

Fixed my ansible task to use the proper path, and therefore also this issue.

I wonder if one should expect rsync to also chown/chmod folders that it creates as part of the destination path?

You must log in to answer this question.

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