[gpfsug-discuss] DACLs and nfs4-acl-tools

Jan-Frode Myklebust janfrode at tanso.net
Mon Feb 26 18:16:47 GMT 2024


It’s not just the nfs4_setfacl tool. Also cp and rsync will fail to cooy
such ACLs.

I have an RFE for this :

https://ideas.ibm.com/ideas/GPFS-I-986



  -jf

man. 26. feb. 2024 kl. 18:27 skrev Robert Horton <robert.horton at icr.ac.uk>:

> Hello,
>
>
>
> We’ve been using nfs4_get/setfacl to manage nfs4 acls as an alternative to
> the mm commands for a few months. It mostly works pretty well – in
> particular it’s simple to set permissions with inheritance flags
> recursively on a directory structure and it’s easy to add an ace for a
> user/group without affecting existing permissions.
>
>
>
> We’ve noticed though that when permissions have been changed via SMB they
> get these DACL ACL flags set:
>
>
>
> # mmgetacl NewTest
>
> #NFSv4 ACL
>
> #owner:ICR\rhorton
>
> #group:ICR\infotech
>
> #ACL flags:
>
> #  DACL_PRESENT
>
> #  DACL_AUTO_INHERITED
>
> #  SACL_AUTO_INHERITED
>
> #  NULL_SACL
>
> user:ICR\rhorton:r-x-:allow:FileInherit:DirInherit
>
> (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL
> (X)READ_ATTR  (X)READ_NAMED
>
> (-)DELETE    (-)DELETE_CHILD (-)CHOWN        (X)EXEC/SEARCH (-)WRITE_ACL
> (-)WRITE_ATTR (-)WRITE_NAMED
>
>
>
> …which upsets nfs4_getfacl:
>
>
>
> # nfs4_getfacl NewTest
>
> # file: NewTest
>
> A::bin:C
>
> Bad Ace Type:768
>
> Error while printing ACE.
>
>
>
> It gets worse if someone does a nfs4_getfacl -R -a <new ace> as it
> sometimes ends up replacing the existing ACEs with one for a ‘bin’ user.
>
>
>
> I’m guessing that with ACL flags present the presented system.nfs4_acl
> extended attribute isn’t in a form that nfs4-acl-tools expects..?
>
>
>
> So…
>
>    1. What do the DACL flags actually do? Where are they stored? Is there
>    a way to check for / modify them? I can see them referenced in
>    https://www.ibm.com/docs/en/storage-scale/5.1.9?topic=users-authorizing-file-protocol
>    but still not entirely clear. Is it possible to get the Samba gpfs module
>    to not set them? I’m guessing not from
>    https://www.samba.org/samba/docs/current/man-html/vfs_gpfs.8.html
>    2. Am I right in thinking this is a Scale bug? If so is it possible to
>    get it fixed 😉 ?
>    3. How do other people manage ACLs?
>
>
>
> Background: It’s an ESS5000. Client access is via a remote mount to an HPC
> system, a large number of Windows/Mac/few Linux SMB clients and a handful
> of NFS (4) clients via CES. We’re on 5.1.9, although the cluster and fs
> versions are a bit behind. -k is nfs4.
>
>
>
> Any thoughts appreciated!
>
>
>
> Thanks,
>
> Rob
>
>
>
> *Robert Horton* | Scientific Computing Infrastructure Lead
>
> The Institute of Cancer Research | 237 Fulham Road, London, SW3 6JB
> <https://www.google.com/maps/search/237+Fulham+Road,+London,+SW3+6JB?entry=gmail&source=g>
>
> *T* +44 (0) 20 7153 5350 | *E* robert.horton at icr.ac.uk | *W* www.icr.ac.uk
> | *Twitter* @ICR_London <https://twitter.com/ICR_London>
>
> *Facebook* www.facebook.com/theinstituteofcancerresearch
>
> *Making the discoveries that defeat cancer*
>
> [image: ICR Logo] <http://www.icr.ac.uk/>
>
>
>
> The Institute of Cancer Research: Royal Cancer Hospital, a charitable
> Company Limited by Guarantee, Registered in England under Company No.
> 534147 with its Registered Office at 123 Old Brompton Road, London SW7 3RP
> <https://www.google.com/maps/search/123+Old+Brompton+Road,+London+SW7+3RP?entry=gmail&source=g>.
>
>
> This e-mail message is confidential and for use by the addressee only. If
> the message is received by anyone other than the addressee, please return
> the message to the sender by replying to it and then delete the message
> from your computer and network.
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at gpfsug.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20240226/671ac45a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3162 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20240226/671ac45a/attachment.gif>


More information about the gpfsug-discuss mailing list