similar to: Problem when excluding unreadable files via pattern and using --fake-super

Hi there I have a LAN with a Linux and a Win2k Computer, using DHCP to connect via Cablemodem to the Internet. So, we don't have fix (private-) ip's. We receive them via the DHCP-Server when starting up the Computers. Now i've setted up samba on my linux (Suse 8.0) computer to share some files (Via NetBIOS on Win, i think). With my current configuration i can see all my shares

Hi list, I'm new on this mailing list and I'm kind of stucked at the moment. I managed to get Postfix and Dovecot working together with Amavis, OpenLDAP und SASL on Ubuntu Linux Release "Dapper Drake". The Dovecot version shipped with Dapper is 1.0-beta3 (at least, that's what the package database tells me), I also tried this with a Debian Backport of version 1.0-rc15.

http://bugzilla.mindrot.org/show_bug.cgi?id=972 Summary: openssh-3.9_p1-r1 login problem Product: Portable OpenSSH Version: 3.9p1 Platform: Other URL: http://bugs.gentoo.org/show_bug.cgi?id=78073 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo:

Hello trusty rsync list, I'm excited about --fake-super as it will replace too much work with none at all. I have gotten it to work under linux and I have a fair grasp with what is happening there. I have a problem, though, and that is, in the long term, I'll need to archive my Linux systems not to a Linux box, but to a Solaris 10 box. I understand that Solaris does have extended

https://bugzilla.samba.org/show_bug.cgi?id=7108 Summary: --fake-super should be nestable Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: matt at mattmccutchen.net

https://bugzilla.samba.org/show_bug.cgi?id=7110 Summary: Symlink fake-super data is silently lost when sys_lsetxattr fails with EPERM Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned at

https://bugzilla.samba.org/show_bug.cgi?id=7112 Summary: --fake-super should use default permissions for real files Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned at samba.org

I'm rsyncing files on system1 to its external HD. system2 is remote and pulls those files from the external HD. system2 does not have root privileges on system1 so I chown the files to pull. Can I somehow use --fake-super or something similar to save the original ownership info to ACLs? - Grant

ln -s real-file symlink file.itself is ./rsync.symlinks/file.itself, but you are trying to link ./file.itself (which presumably doesn't exist) to the real file. Since a symlink is just a pointer, it gets created, but doesn't point to any real file. Try: ln -s rsync.symlinks/file.itself . Joe On 10/11/2015 06:17 AM, Pavel Alexeev wrote: > Hi all. > > I long time discover

https://bugzilla.samba.org/show_bug.cgi?id=11558 Bug ID: 11558 Summary: rsync always try change owner and group of symlink in --fake-super mode Product: rsync Version: 3.1.2 Hardware: x64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: core

Permissions don't require super. Any place where permissions can't be stored certainly can't handle xattrs either. So, I wouldn't expect --fake-super to affect --perms at all. On 3/12/20 12:46 PM, Dimitrios Apostolou via rsync wrote: > rsync --perms -M--fake-super src dst > > For me, this command means that rsync should save the original perms in the > xattr, and

I would expect that the sending rsync would only send the perms provided modified by the --chmod. I wouldn't expect the receiver to even know the other permissions. On 3/12/20 1:23 PM, Dimitrios Apostolou via rsync wrote: > Thank you for the feedback, I'm glad to see that different people see > the issue > differently. As a followup question, what would you expect this to do:

I don't believe it is possible. I think the misunderstanding stems from the fact that the permissions are even stored in the xattr. They don't need to be there but they may as well be. They don't take much space. The real question would be when rsync reads the file to restore it and the file perms are different than the ones in the xattr which set does it use? On 3/16/20 10:01 AM,

I am on rsync version 3.2.7 protocol version 31, currently on an Arch Linux. The following seems I would expect to copy the contents of 'a' to 'c', based on my understanding of the the advice of `man rsync`: ----- mkdir a b c touch a/hello rsync -M--fake-super -a a/ b/ rsync --super -M--fake-super -a b/ c/ ----- Instead I see 'c' unchanged, and a garbage directory

https://bugzilla.samba.org/show_bug.cgi?id=10496 Summary: --itemize-changes always reports xattr changes with --xattrs --fake-super Product: rsync Version: 3.1.1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at

On 05/02/18 23:03, Dave Gordon via rsync wrote: > On 05/02/18 05:53, Wayne Davison wrote: >> On Sat, Feb 3, 2018 at 5:20 AM, Dave Gordon via rsync >> <rsync at lists.samba.org <mailto:rsync at lists.samba.org>> wrote: >> >> [...fake-super symlink saved as a file...] >> >> This results in the copy being world-writable. >> >>

rsync --perms -M--fake-super src dst For me, this command means that rsync should save the original perms in the xattr, and leave the real file mode to the umask default. Currently it also modifies the real file mode, and there is no way to store something different in the xattr. According to an old bug report that I found, more people would like --fake-super to be a complete attribute

On 03/02/18 13:20, Dave Gordon via rsync wrote: > When using fake-super mode in an rsync receiver, anything that's neither a > file nor a directory (e.g. devices, symlinks, etc) is converted into a file, > and properties such as original ownership, filetype, and permissions are > stored in a specific extended attribute. > > In the case of a symlink, the contents of the link

Thank you for the feedback, I'm glad to see that different people see the issue differently. As a followup question, what would you expect this to do: rsync --perms --chmod g+rX -M--fake-super src dst I would expect it to store the original permissions in the xattr, while modifying the real file mode according to the chmod. On Thursday, March 12, 2020 6:06:34 PM CET, Kevin Korb via rsync

Thanks. This is a bit counter-intuitive to me. So how would you tell rsync to store the original permissions in the xattr, but do not touch the real file mode? On Thursday, March 12, 2020 6:26:18 PM CET, Kevin Korb via rsync wrote: > I would expect that the sending rsync would only send the perms provided > modified by the --chmod. I wouldn't expect the receiver to even know > the