Only the top level of the project is root:root, not all files. The owner inherit is like CREATOROWNER in Windows, so the parent owner isn't inherited, but the permission inherits to newly created files.
It was a while ago we worked out our permission defaults but without it we could have users create a file/directory but not be able to edit/change it as whilst the group had permission, the owner didn't. I should note we are all at 5.x code and not 4.2. Simon ________________________________ From: [email protected] <[email protected]> on behalf of Paul Ward <[email protected]> Sent: Tuesday, October 15, 2019 5:15:50 PM To: gpfsug main discussion list <[email protected]> Subject: Re: [gpfsug-discuss] default owner and group for POSIX ACLs An amalgamated answer... > You do realize that will mean backing everything up again... >From the tests that I have done, it appears not. A Spectrum protect incremental backup performs an 'update' when the ACL is changed via mmputacl or chown. when I do a backup after an mmputacl or chown ACL change on a migrated file, it isn't recalled, so it cant be backing up the file. If I do the same change from windows over a smb mount, it does cause the file to be recalled and backedup. > ...I am not sure why you need POSIX ACL's if you are running Linux... >From what I have recently read... https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adm.doc/bl1adm_admnfsaclg.htm "Linux does not allow a file system to be NFS V4 exported unless it supports POSIX ACLs." As I said this system has had roles added to it. The original purpose was to only support NFS exports, then as a staging area for IT, as end user access wasn't needed, only POSIX permissions were used. No it has end user SMB mounts. >“chmodAndSetAcl” Saw this recently - will look at changing to that! https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adm.doc/bl1adm_authoriziefileprotocolusers.htm "To allow proper use of ACLs, it is recommended to prevent chmod from overwriting the ACLs by setting this parameter to setAclOnly or chmodAndSetAcl." >#owner:root OK so you do have root as the owner. > special:owner@:rwxc:allow:FileInherit:DirInherit And have it propagated to children. > group:gITS_BEAR_2019- some-project:rwxc:allow:FileInherit:DirInherit We by default assign two groups to a folder, a RW and R only. > special:everyone@:----:allow > special:owner@:rwxc:allow > special:group@:rwx-:allow I have been removing these. This seems to work, but was set via windows: POSIX: d--------- 2 root root 512 Apr 11 2019 <group> #NFSv4 ACL #owner:root #group:root #ACL flags: # DACL_PRESENT # DACL_AUTO_INHERITED # SACL_AUTO_INHERITED # NULL_SACL group:dg-<group>-ro: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 group:dg-<group>-rwm:rwx-:allow:FileInherit:DirInherit (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED (X)DELETE (X)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED group:dl-<service-desk-access-to-view-permissions>:r-x-:allow:FileInherit:DirInherit:Inherited (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 So is root as the owner the norm? Kindest regards, Paul Paul Ward TS Infrastructure Architect Natural History Museum T: 02079426450 E: [email protected] -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Jonathan Buzzard Sent: 15 October 2019 15:30 To: gpfsug main discussion list <[email protected]> Subject: Re: [gpfsug-discuss] default owner and group for POSIX ACLs On Tue, 2019-10-15 at 12:34 +0000, Paul Ward wrote: > We are in the process of changing the way GPFS assigns UID/GIDs from > internal tdb to using AD RIDs with an offset that matches our linux > systems. We, therefore, need to change the ACLs for all the files in > GPFS (up to 80 million). You do realize that will mean backing everything up again... > We are running in mixed ACL mode, with some POSIX and some NFSv4 ACLs > being applied. (This system was set up 14 years ago and has changed > roles over time) We are running on linux, so need to have POSIX > permissions enabled. We run on Linux and only have NFSv4 ACL's applied. I am not sure why you need POSIX ACL's if you are running Linux. Very very few applications will actually check ACL's or even for that matter permissions. They just do an fopen call or similar and the OS either goes yeah or neah, and the app needs to do something in the case of neah. > > What I want to know for those in a similar environment, what do you > have as the POSIX owner and group, when NFSv4 ACLs are in use? > root:root > > or do you have all files owned by a filesystem administrator account > and group: > <ad service account>:<ad fileserver admin group> > > on our samba shares we have : > admin users = @<ad fileserver admin group> > So don’t actually need the group defined in POSIX. > Samba works much better with NFSv4 ACL's. JAB. -- Jonathan A. Buzzard Tel: +44141-5483420 HPC System Administrator, ARCHIE-WeSt. University of Strathclyde, John Anderson Building, Glasgow. G4 0NG _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgpfsug.org%2Fmailman%2Flistinfo%2Fgpfsug-discuss&data=02%7C01%7Cp.ward%40nhm.ac.uk%7C54e024b8b52b4a70208e08d7517c47fc%7C73a29c014e78437fa0d4c8553e1960c1%7C1%7C0%7C637067466552637538&sdata=v43g1MEBnRBZP%2B5J7ORvywIq6poqhK24fTsCco0IEDo%3D&reserved=0 _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
