On 14/04/2019 01.03, L A Walsh wrote:
On 4/13/2019 2:01 PM, Carlos E. R. wrote:
Now, why does the ACL permission have priority over the filesystem permissions? How can they be different?
Permissions usually are dealt with: 1) more specific permissions are usually give more weight than more general ones.
2) sometimes 'denies' are processed before 'permits' and the search stops on the 1st match encountered.
3) in some systems, ordering is sensitive because, again the search stops on the 1st match.
I will have to think it over, I don't understand that :-)
And why did not rsync copy them? How can I get rsync to really copy them over faithfully?
Are you wanting an incremental copy or a full copy. If 'full', why not use tar?
No. I'm doing a plain file move in two steps, from one disk to another disk. First I copy the files, later I delete them. I do the copy with rsync because I thought it would do a *exact* copy and does checksums. (when the main disk gets full I move videos to the second disk, which is larger, and then create links on the first disk pointing to the videos on the second) (no, I'm not going to setup LVM)
Andrei hints at "mask". I don't understand. With whatever mask, the > filesystem permissions were transferred by rsync perfectly, but not the ACLS. Why?
What were the group permissions supposed to be? rwx?
Yes. And they are, look at "ls -l" output: cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ But on ACL they are "---" instead. And apparently, the ACL permissions supersede the filesystem permissions.
What are the umasks of the running processes -- both on side where rsync is run as well as where it is extracted.
I have no idea. I never look at that, nor change it. But: cer@Isengard:~> umask 0022 cer@Isengard:~>
I.e. If the extracting site has a mask of 077, its possible rsync would consider that to be a hint that group perms should be excluded.
It is the same computer, just across two separate disks. A single process AFAIK.
Also -- the 'default/inherited acl' on the directory -- Is there one?
I have no idea. If that's something I have to do manually, I did not. I don't know how to check it, or how to set it. There is a cronjob (by root, /etc/cron.daily/mio.videos) that is supposed to do: find /home/cer/Fusion/Videos/ -type d | \ parallel "chown cer:cer ''{}'' && \ chmod u+r+w+x,g+w+x,o+r-w-x,+t ''{}'' && \ chown cer-g:cer ''{}'' && \ setfacl -m u:wwwrun:rx ''{}'' " find /home/cer/Fusion/Videos/3_MyBook_Videos -type d | \ parallel "chown cer:cer ''{}'' && \ chmod u+r+w+x,g+w+x,o+r-w-x,+t ''{}'' && \ chown cer-g:cer ''{}'' && \ setfacl -m u:wwwrun:rx ''{}'' " But it has not run or has failed, because it should have set ownership of the directories to "cer-g" and it is still "cer". I'm not investigating that till I solve the current issue. I'll have to add to it set the ACL group permission, too.
Might that be adding to the mix, by starting with acls for child inodes from that one?
I'm afraid I don't understand.
From the 'chacl' man page:
Changing the permission bits of a file will change the file access ACL settings (see chmod(1)). However, file creation mode masks (see umask(1)) will not affect the access ACL settings of files created using directory default ACLs.
Too tired to write more right now...
Yeah, here is is 2 AM. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)