4

I'm trying to use the https://unix.stackexchange.com/a/315667/21372 workaround to the cp bug using rsync, and I can't get it to work. Essentially, I need to copy files or directories recursively using rsync similar to what rsync -a would do, but create files and directories with normal umask conditions. But trying this on a single file shows that it is still preserving permissions on the destination file even though I have specified the --no-perms option:

bash-4.1$ cd /tmp
bash-4.1$ touch afile
bash-4.1$ chmod a-w afile
bash-4.1$ ls -ld afile
-r--r--r-- 1 theuser thegroup 0 Jul 24 16:50 afile
bash-4.1$ rsync --copy-links --recursive --times --group --no-perms afile afile2
bash-4.1$ ls -ld afile*
-r--r--r-- 1 theuser thegroup 0 Jul 24 16:50 afile
-r--r--r-- 1 theuser thegroup 0 Jul 24 16:50 afile2
bash-4.1$

What I want is the afile2 to have the same permissions as afile3 created normally:

bash-4.1$ touch afile3
bash-4.1$ ls -ld afile3
-rw-rw-r-- 1 theuser thegroup 0 Jul 24 16:51 afile3

I can use the "harsh" find command as given in https://unix.stackexchange.com/a/315667/21372 but I'd rather not have the overhead of a subsequent find command to do what I believe the rsync --no-perms option should do.

This needs to work in userspace (not require root).

Is this an rsync bug or user error?

OS and version of rsync involved are:

bash-4.1$ lsb_release -r -i
Distributor ID: RedHatEnterpriseWorkstation
Release:    6.8
bash-4.1$ rsync --version
rsync  version 3.0.6  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
bash-4.1$
bgoodr
  • 197
  • 2
  • 8

2 Answers2

4

From the rsync man page:

To give new files the destination-default permissions (while leaving existing files unchanged), make sure that the --perms option is off and use --chmod=ugo=rwX (which ensures that all non-masked bits get enabled).

So...

rsync --copy-links --recursive --times --group --no-perms --chmod=ugo=rwX afile afile2

... should do the trick with the example files you showed.

If the source files have permissions of, say 777...

rsync --copy-links --recursive --times --group --no-perms --chmod=ugo=rw,-X afile afile2

... will remove the executable flag.

cmerriman
  • 176
  • 1
  • right answer, but wrong reason. with `-no-perms --chmod=ugo=rwX`, the source file's permissions are irrelevant. The destination file's permissions are the umask (or directory ACL or however else the default perms might be defined) masked with `ugo=rwX`. so if, e.g., umask is 0022, the dest file will be 644...and if umask is 0002, the dest file be be 664. Although rsync's man page doesn't say so, it seems that the default is `--chmod ugo=r`. – cas Jul 25 '17 at 01:19
  • I would agree that --no-perms should make the source file permissions irrelevant, but in testing that was not the case. With source permissions of 444 and ugo=rwX and umask 0022 the resulting file was 644. With source file at 777 the resulting file was 755.. – cmerriman Jul 25 '17 at 01:46
  • weird. with my testing, only the umask and the --chmod option made any difference to the target's permissions. – cas Jul 25 '17 at 01:50
  • 1
    ah, i see where you're getting confused. the "ugo=X" in the --chmod preserves the execute bits for ugo, overriding the `--no-perms` for the execute bits only. Try it with source file perms = 777, and `--chmod=ugo=rw` in the rsync command. – cas Jul 25 '17 at 01:55
  • 1
    ugo=rw does work as you describe. Interesting that the man page specifies to use ugo=rwX. – cmerriman Jul 25 '17 at 02:03
  • 1
    It probably assumes people want to preserve execute bits (which is not unreasonable when rsyncing executables and directories). Anyway, it's just an example (but IMO it should make the effort to point out how X will interact with --no-perms). – cas Jul 25 '17 at 02:06
  • "make the effort" is correct. https://linux.die.net/man/1/rsync references the `--chmod` option, but my version (in original post) does not. Hence why I didn't know it existed. But, the option does work. – bgoodr Jul 25 '17 at 17:13
0

I wanted to copy dir without ownership and permission preservation with a specific umask. And hit same issue. I also wanted to preserve executable bit (but no other permissions). Reading man rsync I've got a similar result to @cmerriman

rsync -rEltDHv --chmod=ugo=rwX src_dir/ dst_dir/

One major difference from the other answer is -E which preserves the execute bit. Other than that the magix seems to be done by --chmod=ugo=rwX which is suggested in the man pages.

akostadinov
  • 944
  • 10
  • 19