similar to: Setting destination permissions while keeping real permissions in xattr

I noticed that rsync sometimes miscalculates the permissions of the top-level destination directory when --perms is off. For example, run these commands in an area free of default ACLs: umask 0000 mkdir -p src/foo chmod 700 src src/foo rsync -r src/ dest/ find . -ls 763054 0 drwx------ 4 matt matt 96 Feb 16 17:57 . 763158 0 drwx------ 3 matt matt 72 Feb 16

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 have a script that syncs my backups to an NFS mount every day The script works fine, without any errors, but there is a problem when it comes to some large files Let's take my pst file (8.9 gig) as an example Source: du -hs mypst.pst 8.9G mypst.pst ls -alh mypst.pst -rw-rw---- 1 me me 8.9G Jan 25 17:07 mypst.pst That seems OK Let's do that on the destination: du -hs mypst.pst

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

Why does --xattrs imply --perms (according to the man page)? Unlike --acls, --xattrs is not logically a superset of --perms (since system.* xattrs are ignored). I might conceivably want to copy some user xattrs that I set on my files while allowing the destination permissions to take the default value. Matt

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

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:

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 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,

Hello list! Combining -M--fake-super with --chmod ends up changing the permissions stored in the fake-super xattrs. I.e. the permissions stored in the xattr, are affected by --chmod. The desirable behaviour for me would be for --chmod to modify the real permissions of the destination files. The use case is writing a backup as a non-root user, having it readable by the group (g+rX), while also

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

When I try it the chmod works on both the real permissions and the permissions in the xatttr. Maybe the behavior has changed since whatever version you have (3.1.3 here) but this probably wouldn't help you either. On 12/8/19 7:56 PM, Dimitrios Apostolou via rsync wrote: > Hello list! > > Combining -M--fake-super with --chmod ends up changing the permissions > stored in the

I've been wrestling with a problem on newer versions of samba with a configuration that "used" to work in samba 3.0.33 (RedHat Enterpise 5 packages) This maybe due to changes in the may samba maps NT permissions, but i'm not sure so I thought I would ask. I have a samba 3.3.8 (RedHat Enterprise 5.5 Samba3x packages) and samba 3.4.4 (Redhat Enterprise 6 beta packages)

Hi Everyone, I have a really huge trouble with the Acls under windows 7. I use filesystem's acls under samba and it works correctly under windows xp, but it does not in w7. I am not sure if it is a kind of bug, the case is last week I upgraded my samba 3.0 to 3.5 and my acls under w7 worked fine. Now the problem I have is if a directory is set for example with the grup 'company' and

Hiya if the rsync options -pgo (preserve perms, group perms, owner perms) are not set, from where does rsync attain the file permissions? Will it just take the default ones from the server? Also, what is the difference between -p and -g or -o ? Thanks Hamish

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

Hi,all when i doing brick rebalance , i found a lot ?failed to get the 'lin kto' xattr Permission denied" message in the mount log file,how can i target the problem source ? what does mean this messages? message sample: [2012-11-02 11:01:47.113326] W [client3_1-fops.c:1128:client3_1_fgetxattr_cbk] 4-kvm-vol-3-client-6: remote operation failed: Permission denied

Aargh, I'm about to give up. Is there someone who knows how to setup Cervisia on SuSE 9.3? I installed the one bundled with it, but somehow it refuses to produce any traffic whatsoever (I checked with 'iptraf'). No surprise I can't connect to the NUT CVS server. I'm able to use CVS by commandline (ssh keys are uploaded and I no longer have to enter a password, so this works

Hi all, I'm trying to setup rsync for backup purpose. Both client and server (storage) are using rsync 3.0.7 delivered by Debian Squeeze. The client invokes rsync using ssh (as root): Backup: rsync --archive --delete --exclude-from=/etc/backup.excludes --numeric-ids --relative --rsh=ssh / backup at example.com::backup/ Restore: rsync --archive --delete --numeric-ids --relative --rsh=ssh

added: --no-compare-xattrs --no-compare-extra-stats --no-compare-perms --no-compare-uids --no-compare-times to ignore specified files informations when comparing. The current strategy to disable comparison on file informations is to flatten data structure so they return the same 0/NULL value on comparison and be, in fact, ignored to determine if the files differ. This patch preserve original