samba-bugs at samba.org
2021-Apr-01 18:11 UTC
[Bug 14683] New: failed to set permissions on symlinks; need `--omit-link-permissions` option
https://bugzilla.samba.org/show_bug.cgi?id=14683 Bug ID: 14683 Summary: failed to set permissions on symlinks; need `--omit-link-permissions` option Product: rsync Version: 3.2.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayne at opencoder.net Reporter: me at shadsterling.com QA Contact: rsync-qa at samba.org Target Milestone: --- After updating to 3.2.3 (along with updating other packages) I'm getting errors of the form `rsync: [generator] failed to set permissions on "/blah/blah/blah": Operation not supported (95)` on symlinks. I assume the underlying OpenSuse system doesn't support setting permissions on symlinks, but I do want to sync permissions on everything but symlinks without getting these errors. I think fixing this would require an option like `--omit-link-permissions` similar to the existing option `--omit-link-times` -- You are receiving this mail because: You are the QA Contact for the bug.
samba-bugs at samba.org
2021-Apr-07 15:17 UTC
[Bug 14683] failed to set permissions on symlinks; need `--omit-link-permissions` option
https://bugzilla.samba.org/show_bug.cgi?id=14683 --- Comment #1 from Ciprian Dorin Craciun <ciprian.craciun at gmail.com> --- I've encountered a similar situation, but with OpenAFS, which for some reason reports the protection for symlinks as `rwxr-xr-x`. Thus using `rsync` with `--perms` and targeting an OpenAFS folder fails with a similar error stating that it can't `chmod` the permissions for that symlink. I am similarly using 3.2.3 on OpenSUSE Tumbleweed (the client) and the same version on OpenSUSE Leap 15.2 (the server). A few monts ago (say January) I've not encountered this error (I'm using the same scripts as before). In essence to reproduce this issue one just has to: ~~~~ mkdir /tmp/source ln -s /dev/null /tmp/source/some-symlink stat /tmp/source/some-symlink # Access: (0777/lrwxrwxrwx) Uid: (1000/ ciprian) Gid: (1000/ ciprian) mkdir /afs/.../target ln -s /dev/null /afs/.../target/some-other-symlink stat /afs/.../target/some-other-symlink # Access: (0755/lrwxr-xr-x) Uid: (33025/ UNKNOWN) Gid: (1000/ ciprian) # up to here we've checked that the source file-system behaves normaly while OpenAFS forces the protection I've stated. rsync -r -p -i --links /tmp/source/some-symlink /afs/.../target/ rsync: [generator] failed to set permissions on "/afs/.../target/some-symlink": Operation not supported (95) cL+++++++++ some-symlink -> /dev/null rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3] ~~~~ (The same happens when the target is via SSH.) -- You are receiving this mail because: You are the QA Contact for the bug.
samba-bugs at samba.org
2021-Apr-07 19:00 UTC
[Bug 14683] failed to set permissions on symlinks; need `--omit-link-permissions` option
https://bugzilla.samba.org/show_bug.cgi?id=14683 --- Comment #2 from Ciprian Dorin Craciun <ciprian.craciun at gmail.com> --- (In reply to Ciprian Dorin Craciun from comment #1) Trying to `strace` what `rsync` does in my OpenAFS use-case I've found that the only syscals invoked by `rysync` (and pertaining to the file in question) are: * `readlink`; * `newfstatat`; * `openat`; * `symlink`; Furthermore, none of them actually fail, instead it seems that the "Operation not supported (95)" is actually generated internally (although I couldn't easily identify its origin). -- You are receiving this mail because: You are the QA Contact for the bug.