ACL disagreement

Daniel Fussell dfussell at
Thu Aug 25 12:35:01 MDT 2016

After some recent distribution and kernel updates, I've got a few XFS
filesystems with ACLs that are messed up in interesting ways.  They are
normally exported by NFSv3 and recently NFSv4 as well, though only a few
clients are mounting with NFSv4. 

The permissions are messed up on only a few files in the following way:

ls -l sink.jpg
-rwxrwxr-x+ 1 user1  user1  4033 Aug 25 10:08 sink.jpg

getfacl sink.jpg

# file: sink.jpg
# owner: user1
# group: user1
user:www-data:r-x               #effective:---
group::r-x                      #effective:---

Just to clarify the issue, the unix permissions show sink.jpg
permissions as 0775 and the '+' indicating a posix draft acl is in
force.  Notice that the user permissions don't match, the unix group
permission and the posix mask permissions don't match (and they should),
and the other permissions don't match. 

Using cp --preserve=all sink.jpg to sink.jpg.bak duplicates the posix
draft acl, but creates unix permissions of 0000 (yeah, no unix
permissions at all).  Without preserve, it inherits permissions as from
the directory as normal.

Touching a new file creates unix perms and posix acls that match.  Using
chmod to change any permission bit also changes the same bit in the
posix acl.  Using setfacl to change any permission bit modifies the
posix acl accordingly, and the unix permissions are then rewritten to
match the posix acl.  I thought the posix acls only stored the named
users, groups, and the mask, and the owning user/group, and other were
derived from the unix permissions.  But it appears they after mutually
independent structs for their permissions.

Has anybody else seen this after an upgrade, and if so, what did you do
to correct it en masse.  Did you ever see the problem show up again?


More information about the PLUG mailing list