See also the comments on the "use chroot" set‐ The numeric ID from the source system is used instead. If a user or group has no name on the source system or it has no match on the destination system, then Special uid 0 and the special group 0 are never mapped via user/group names even if the -numeric-ids With this option rsync will transfer numeric group and user IDs rather than using user and group namesīy default rsync will use the username and groupname to determine what ownership to give files.
#Grsync canot open display full
ID number in some circumstances (see also the -numeric-ids option for a full discussion). The preservation of ownership will associate matching names by default, but may fall back to using the Without this option, the owner of new and/or transferred files are set to the invoking user This option causes rsync to set the owner of the destination file to be the same as the source file,īut only if the receiving rsync is being run as the super-user (see also the -super and -fake-super That should preserver the correct ownership when you reverse the rsync direction and restore the backup. Rsync will then preserve the actual underlying UID/GID numbers and the UID number of the vmail user on the source will used to set the owner. When no matching user vmail is present on the remote destination, then a fall-back scenario will happen. That is usually quite resilient and the most predictable for humans as we normally don't look at ownership in the form of UID/GID numbers. In other words when the user vmail is the owner of a file at the source, rsync will make the user vmail also the owner at the destination (even when they have different UID/GID numbers). Users and groups with the same names can have different UID/GID numbers on different systems.īy default rsync will try to match the ownership by username resp. When there is no mapping from UID/GID's to usernames and groupnames tools will simply display those numbers instead. The -a option includes the -o, -owner, -g, -group options designed to preserve ownership.Īt the file-system level user and group ownership is stored in UID resp. Otherwise you can't create files and directories with a different user other than your own. But rsync still does its false "success" thing.How rsync preserves ownership of files depends on two things:Īre you super-user (root) on the destination? I can look at all the directories on it in Nautilus. I can get onto the NAS by logging on with username/pswrd. I have a bookmark to the destination directory on the NAS, but I get the mounting error when I click on it. This was months ago and I forget the details. That had happened before but stopped "back in the day" and grsync started working. Why? I haven't done anything to the system (besides try to use it). I'm also getting errors mounting the NAS drive. I suppose this is related, maybe The cause, but I don't know what to do about it either. But after a few times like that, I checked the destination drive - and nothing had been updated. When it first happened I thought I just hadn't changed that many files. Now I choose a multi-job process, it finishes in less than a minute. It was great when it finally started working, but no more. I'd especially like to use it for all common directories just before I travel. I'd like to use it daily for a limited number of my most commone directories.
0 kommentar(er)
