similar to: Setting perms w/o using root

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

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

Hello, As i cannot get 3.0.0pre5 to work in my environment (throwing crazy errors which i've posted previously), i would like to revert to 2.6.9 . Of course, the reason i tried to use v3 in the first place was for the acl, xattr, and fake-super options - which, evidently, can be enabled under 2.6.9, as per the following sources: http://lists.samba.org/archive/rsync/2007-February/017218.html

https://bugzilla.samba.org/show_bug.cgi?id=7070 Summary: Permission denied message with --fake-super and permissionless directory Product: rsync Version: 3.0.6 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at

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

Can I adjust the ssh daemon to log IP addresses instead of hostnames? I assume this situation is feasible... * 10.10.10.10 attempts to ssh to the server * reverse dns resolves to "somehost.domain.com" * ssh daemon logs "somehost.domain.com" in messages * foward dns on "somehost.domain.com" resolves to 10.10.10.20 Thus it causes some of my scripts a problem if the

# rpm -qa | grep kernel-2 | sort kernel-2.6.9-42.0.10.EL kernel-2.6.9-42.0.2.EL kernel-2.6.9-42.0.3.EL kernel-2.6.9-42.0.8.EL kernel-2.6.9-42.EL kernel-2.6.9-55.0.2.EL kernel-2.6.9-55.0.6.EL kernel-2.6.9-55.0.9.EL kernel-2.6.9-55.EL I'm running the most recent kernel available, and I've never had a problem with any past kernels, so I don't believe there's any reason to keep all of

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

So both "yum upgrade" and "yum update" now are complete and there's no new packages. However, when I attempt to check my version, I'm still showing 5. # cat /etc/redhat-release CentOS release 5 (Final) I remember seeing 5.1 repositories being access for the upgrades. Is it possible my system did not upgrade? # uname -r 2.6.18-53.1.4.el5.centos.plus Thanks, Scott

# rpm -qa | grep -E '^(java|jdk|jre)-' jre-1.6.0_03-fcs java-1.4.2-gcj-compat-1.4.2.0-27jpp jdk-1.6.0_03-fcs java is a CentOS package. jdk and jre are from Sun. (I need Java >= 1.5.0 for an application I'm installing.) # update-alternatives --config java There are 1 programs which provide 'java'. Selection Command ----------------------------------------------- *+

I have an ext3 partition from our SAN. The size was increased. I am attempting to re-size this specific ext3 partition, obviously. I unmount the partition, run fdisk, change the cyls, and save... WARNING: Re-reading the partition table failed with error 22: Invalid argument. The kernel still uses the old table. The new table will be used at the next reboot. And that is the message that I

I have a simple script that sends one file to two locations on the same destination server. Here's the code: DEST="remotehost" SRC="/home/boss/application.conf" DST1="/home/user1/application.conf" DST2="/home/user2/application.conf" RSYNC1=`rsync -caW -e ssh $SRC $DEST:$DST1` RSYNC2=`rsync -caW -e ssh $SRC $DEST:$DST2` This runs every 5 minutes. What

I removed an ATA drive (/home) for a new SATA and my system would not boot. I'm guessing that it put the MBR on that drive instead of the drive that holds the / partition. What's the best way confirm where the MBR resides and, after I verify that's my problem, how I can move (or make a copy) onto a different drive? Thanks, Scott

I'm looking to see of it is practical to have an rsync server run a script after a transfer finishes. I am moving files (python source) from windows (common point of development) to a few linux machines. big problem being owner/group/perms are always wrong and python's module install process is fragile with respect to OGP. Therefore, I want to run a script after transferring a set

Hi, we needed these changes when we had to build a guest image compatible with a starting guest image but not backed by it in any way? We needed some tool to check our progress, comparing original and? rebuilt (from scratch) images, and virt-diff seemed the best option, but? we had to soften the comparison to reduce the noise in the output. I added some options to ignore certain informations when

https://bugzilla.samba.org/show_bug.cgi?id=6590 Summary: [sender] could not find xattr #1 for home/jdoe/TheFresh Product: rsync Version: 3.0.5 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: stlman at

When using --link-dest, this block of code in skip_file causes new copies of files to be created if source and destination file permissions differ, even if -p -o and -g haven't been specified. if (link_dest) { if((st->st_mode & ~_S_IFMT) != (file->mode & ~_S_IFMT)) { return 0; } if (st->st_uid != file->uid || st->st_gid != file->gid) { return 0; } }

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 are stored in a plain file. The original mode of the symlink is normally

Centos 4.3 Hi All: I just shot myself in the foot by change the owner/perms on the contents of the root directory (my bad!!!). I have done a quick compare with a running RHEL3U8 system and think I have every thing back to what it should be except for new directories media and selinux. Can someone out there currently running 4.3 send me an "ls -l" of their root directory so I can make