On Fri, 12 Apr 2019 16:15:31 -0400 Patrick Shanahan wrote:

* Carlos E. R. [04-12-19 16:04]:

...

In a nutshell:

cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ [snip www and wwwrun are groups themselves. add user cer-g to wwwrun group.

But why? The directory belongs to group cer and gives all permissions to members and cer-g is a member of cer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/04/2019 22.34, Dave Howorth wrote:

On Fri, 12 Apr 2019 16:15:31 -0400 Patrick Shanahan wrote:

...

* Carlos E. R. [04-12-19 16:04]:

...

In a nutshell:

cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ [snip www and wwwrun are groups themselves. add user cer-g to wwwrun group.

But why? The directory belongs to group cer and gives all permissions to members and cer-g is a member of cer.

I'm running fsck on it. Isengard:~ # mount | grep My /dev/mapper/cr_my_book on /data/My_Book type xfs (rw,nosuid,nodev,relatime,lazytime,attr2,inode64,noquota,user) Isengard:~ # umount -v /data/My_Book umount: /data/My_Book (/dev/mapper/cr_my_book) unmounted Isengard:~ # fsck /dev/mapper/cr_my_book fsck from util-linux 2.31.1 If you wish to check the consistency of an XFS filesystem or repair a damaged filesystem, see xfs_repair(8). Isengard:~ # man xfs_repair Isengard:~ # xfs_repair /dev/mapper/cr_my_book Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Isengard:~ # cer-g@Isengard:~> cd /data/My_Book/Fusion/Videos cer-g@Isengard:/data/My_Book/Fusion/Videos> cd Conviction/ -bash: cd: Conviction/: Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> No luck. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 13/04/2019 03.57, L A Walsh wrote:

On 4/12/2019 1:02 PM, Carlos E. R. wrote:

...

In a nutshell:

cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/

So for user 'cer' and group 'cer' have access: 'rwx', but other has access 'r-- on a directory. That means noone should be able to look for objects in the directory,

noone except cer and members of the group cer, and cer-g is a member of that group, yet has not access.

but dos allow reading the directory -- never quite sure about exactly what that would give in permissions, but I'd turn on the 'x' bit along with the 'r' bit on a directory, like:

chmod o+rx Conviction

Is that the prob you were looking for?

No, but does not work: cer@Isengard:/data/My_Book/Fusion/Videos> chmod o+rx Conviction cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-x+ 3 cer cer 33 Jun 21 2017 Conviction/ cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> Tomorrow I will update that machine and reboot it, and see. This is absurd. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 4/12/2019 7:41 PM, L A Walsh wrote:

as far as you know, are there acls on the dir or just standard perm bitS?

Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access? not sure how that would get there though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

13.04.2019 13:36, Carlos E. R. пишет:

On 13/04/2019 06.46, Andrei Borzenkov wrote:

...

12.04.2019 23:02, Carlos E. R. пишет:

...

User "cer-g" is member of groups "users" and "cer"

Directory has group permission "rwx"

It does not.

No, group has "rwx".

Sigh ... if you know everything why do you even ask in the first place? And if you ask, may be you can accept the fact that those who answer may actually know what they are talking about?

Group ACL as "---". I thought the main permissions had priority.

Read "man 5 acl", especially sections "CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS" and "ACCESS CHECK ALGORITHM".

...

...

and is owned by "cer:cer" Same for parent directory.

The user "cer-g" is denied access to the directory "Conviction/" and others.

Why?

File permissions deny access to members of file group.

No, ACL permissions deny access.

Sigh again ... they *are* permissions bits. The fact that ls displays ACL mask instead of group permissions does not change the fact that group permissions deny any access to group.

...

...

I also have this:

cer-g@Isengard:/data/My_Book/Fusion/Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer # flags: --t user::rwx user:wwwrun:r-x group::--- ^^^^^^^^^^^^ mask::rwx other::r--

Yes, I thought of that this morning, but it is not my doing.

So what? You asked why you cannot access this directory and this is the answer.

The command I used to set ACLSs was:

setfacl -m u:wwwrun:rx

The file was copied from another directory, by rsync.

Original file:

cer-g@Isengard:~/F_Videos/1_Almacenar> getfacl Conviction # file: Conviction # owner: cer-g # group: cer # flags: --t user::rwx user:wwwrun:r-x group::rwx <===== mask::rwx other::r--

copied file:

cer-g@Isengard:~/F_Videos/1_Almacenar> cer-g@Isengard:~/F_Videos/3_MyBook_Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer user::rwx user:wwwrun:r-x group::--- <==== mask::rwx other::r--

How has the ACL changed ?

ACL did not change. Group permissions changed. Trivial answer is umask. Less trivial answer is default ACL on parent directory. You are in the best position to debug it as only you can reproduce it in your environment.

(the 't' I deleted yesterday)

The command to copy the files was:

cer@Isengard:~> time rsync --archive --acls --xattrs \ --hard-links --sparse --stats --human-readable \ --checksum /data/waterhoard/Fusion/Videos/1_Almacenar/ \ /data/My_Book/Fusion/Videos/

I told rsync to keep the ACLS, but it has modified them.

On 4/13/2019 5:32 AM, Carlos E. R. wrote:

On 13/04/2019 14.24, Andrei Borzenkov wrote:

...

13.04.2019 13:36, Carlos E. R. пишет:

...

Yes, I thought of that this morning, but it is not my doing.

So what? You asked why you cannot access this directory and this is the answer.

Sigh. You always have to be so blunt?

==== Apparently. I gave you the same answer as Andrei, two hours earlier, but I phrased it in the form of an exploratory question and it got ignored: On 4/12/2019 7:45 PM, L A Walsh wrote:

Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access?

not sure how that would get there though.

================== Any people often wonder why they don't see more women contributing in technical fields -- maybe they just need to be more blunt? Of course when she is, there'll be hell to pay. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 13/04/2019 22.13, L A Walsh wrote:

On 4/13/2019 5:32 AM, Carlos E. R. wrote:

...

On 13/04/2019 14.24, Andrei Borzenkov wrote:

...

13.04.2019 13:36, Carlos E. R. пишет:

...

Yes, I thought of that this morning, but it is not my doing.

So what? You asked why you cannot access this directory and this is the answer.

Sigh. You always have to be so blunt?

==== Apparently. I gave you the same answer as Andrei, two hours earlier, but I phrased it in the form of an exploratory question and it got ignored:

On 4/12/2019 7:45 PM, L A Walsh wrote:

...

Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access?

not sure how that would get there though.

==================

Hey, I did not ignore it! I replied to it, but inside a reply to a previous post from you 5 minutes earlier. I combined my reply in just one post. I saw both yours and Andrei's when I switched on the machine in the morning, his was nearer the edge of the display and read it first. I did notice the ACLS were weird since my very first post. I said «But the line "group::---" confuses me». Those were not the ACLS permissions /I/ had wrote on the directory, they were different. And I thought that filesystem permissions had precedence over ACLS. So I posted hoping for comments. :-)

Any people often wonder why they don't see more women contributing in technical fields -- maybe they just need to be more blunt? Of course when she is, there'll be hell to pay.

I appreciate your posts, you often nail issues. So does Andrei, but he was so blunt that I ignored most of his post in anger. Anyway, the problem was caused by this command: cer@Isengard:~> time rsync --archive --acls --xattrs \ --hard-links --sparse --stats --human-readable \ --checksum /data/waterhoard/Fusion/Videos/1_Almacenar/ \ /data/My_Book/Fusion/Videos/ Notice that the process is run by "cer", and that I ask rsync to keep ACLS by using "--acls". The original directory had this set of permissions (says ls -l and getfacl): drwxrwxr-T+ 3 cer-g cer 33 Jun 21 2017 Conviction/ # file: Conviction # owner: cer-g # group: cer # flags: --t user::rwx user:wwwrun:r-x group::rwx <===== mask::rwx other::r-- and the copied directory instead had this set: drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ # file: Conviction # owner: cer # group: cer user::rwx user:wwwrun:r-x group::--- <==== mask::rwx other::r-- The user ownership changes from cer-g to cer because the process is run by cer. Group remains the same. Filesystem permission set remains the same, but ACL permissions change. flag 't' is lost on destination because the instant I took the "photo" I had already removed it. Yesterday it was there, so ignore that. Everything is the same, except this line: "group::rwx" changes to: "group::---" I changed that manually, and now I can access the directory. I still have to run a find query to do the same on the entire archive, but that will wait. Now, why does the ACL permission have priority over the filesystem permissions? How can they be different? And why did not rsync copy them? How can I get rsync to really copy them over faithfully? Andrei hints at "mask". I don't understand. With whatever mask, the filesystem permissions were transferred by rsync perfectly, but not the ACLS. Why? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

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)