[LU-13051] ACL fail on some clients or mount points Created: 06/Dec/19  Updated: 12/Feb/20  Resolved: 12/Feb/20

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mahmoud Hanafi Assignee: Peter Jones
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
is related to LU-12657 sanity/103 and sanityn/25 fail with 4... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

Sometimes set ACLs will fail on one client but will work on a different client or on a new mount on the same client.
And it can be work intermittently.

We started to see this with

Clients:
lustre2.12.2 clients and sles11sp4

Servers:
lustre2.10.8 and lustre2.12.2

For example (I changed the real user and group names)

pfe22 ~ # getfacl /nobackupp2/t12345n
getfacl: Removing leading '/' from absolute path names
# file: nobackupp2/t12345n
# owner: t12345n
# group: s0123
user::rwx
user:data123:r-x
group::---
group:s0123:r-x
mask::r-x
other::---

pfe22 ~ # su - data123 -c "ls /nobackupp2/t12345n"
ls: cannot open directory '/nobackupp2/t12345n': Permission denied

pfe22 ~ # mkdir /nobackupp2_new
pfe22 ~ # mount -t lustre 10.151.26.96@o2ib:/nbp2 /nobackupp2_new
pfe22 ~ # su - data123 -c "ls /nobackupp2_new/t12345n"
test


 Comments   
Comment by Mahmoud Hanafi [ 06/Dec/19 ]

I uploaded 2 debug trace one that shows acl working and one that doesn't
ftp.whamcloud.com/uploads/LU-13051/p24_worked_lookup.debug.out
ftp.whamcloud.com/uploads/LU-13051/p22_failed_lookup.debug.out

Comment by Peter Jones [ 06/Dec/19 ]

mhanafi could this be a duplicate of LU-12657? It usually affects newer kerrnels but SUSE could well have back ported something significant...

Comment by Mahmoud Hanafi [ 10/Dec/19 ]

It could be a duplicate of LU-12657. We'll update to 2.12.3 and see if we still see the issue.

Comment by Mahmoud Hanafi [ 12/Feb/20 ]

Please close no longer an issue in 2.12.3

Comment by Peter Jones [ 12/Feb/20 ]

ok - thanks

Generated at Sat Feb 10 02:57:56 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.