Is there any way to force a user created file to be of a specific group within a folder/directory or a particular mount point? Specifically on an ext4 file system. I can do this on cifs mounts. I’ve read man; mount, fstab and ext4. All those describe permissions for mounting but not subsequent file creation.
1 Like
So I found this thread here:
Set group permissions on folder
There are a few more steps based on other search results.
chgrp GROUPNAME /path/to/directory
chmod g+s /path/to/directory
find /path/to/directory -type d -exec chmod g+s {} +
setfacl -d -m group:GROUPNAME:rwx /path/to/directory
setfacl -m group:GROUPNAME:rwx /path/to/directory
find /path/to/directory -type d -exec setfacl -m d:g::rwx {} +
I still need to do some testing.
2 Likes
OK, all is working. Groupname member user can create new file with groupname group ownership with rw permissions. Same with new folders which have setgid bit.
Hope this self answered question helps others as it did me.
1 Like
Yes, the setgid bit is nice, but not always enough.
The default is that created files do get the uid and gid of the process that creates them.
The setgid bit overrides the gid with the gid of the directory, where the file is created (and sets the setgid bit, if created file is a directory).
However, that is for created files. If you do move existing file from elsewhere, it does already have gid set and likely retains that gid. (If you do rsync -a, then you definitely keep the existing gid, if possible.)
For that reason you want the FACL that the group of you choice does have write access in addition to POSIX attributes. (Although, rsync -aA can probably ruin that too. The rsync does have --chown and --chmod options.)
1 Like
That makes sense. I will have to test if the facl’s override that. The main use case is copy from desktop or downloads with what ever DE tools are involved. I do use scp and that does seem to conform to destination “ug” rules. I’ll test with -p to see what affect that has.
1 Like
I did some simple copies from local and remote hosts with basic copy and scp -p. In all cases the group was changed to the assigned group in the destination folder but the permissions remained unchanged from the source meaning if the source is 644 it remains as such. New files created by group members are created with group rw permissions.
So I’m not quite there yet.
1 Like
The permissions for new files do default to 777 and 666 (for directories and files, respectively) with umask removed.
The RHEL default is that umask is 002, if effective groupname is equal to username. Others (and root) get 022.
The RHEL default is that the primary group of account (and hence usually the effective) has same name as the account. The private group. Hence those users create files with 775 and 664 (and in setgid directory 2775 and 664).
The scp is no longer recommended, because it has some security issues. The sftp and rsync are better.
Did the copied files get the ACLs? Didn’t you have ACL to override the group’s permissions with g+rw?
PS. Read about permission X from man chmod. It helps as one does not have to chmod directories and files separately (for executability).
1 Like
The default umask on RL9 is 022 in all cases for root or logged in user.
No, the copied file did not inherit the group g+rw set on the destination folder.
I haven’t looked at the chmod -X option. Since most file transfers are done through cifs shares the smb.conf settings are providing the correct group membership and perms upon file transfer.
I was just trying to catch the edge case that is for the most part my own doing and not other users.
1 Like
Oh my, how have I missed that? 
Thanks for correcting.
1 Like
EL9 did set umask for non-login shells differently from login shells, until
https://access.redhat.com/errata/RHBA-2023:2552 that is EL 9.2, last May.
* Thu Oct 24 2022 Martin Osvald <mosvald@redhat.com> - 2.13.7-8
- Set default umask for non-login shell only if it is set to 0 (#2062601)
Interestingly, the RHEL 9 docs are still https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_basic_system_settings/assembly_managing-the-umask_configuring-basic-system-settings with old content.
Regardless, if I create file from command-line with umask 0002, it does get g+w, but if I use the GNOME Files GUI, it acts g-w. That too is inconsistent (and I tend to miss it as I dont’ usually use GUI).
Tested on ext4:
$ mkdir xxx
$ setfacl -d -m group:ptest:rwx xxx
Copied two files; one with cp, other with ‘Files’, i.e. “drag-n-drop”.
$ getfacl xxx/f*
# file: xxx/file_trans_eplg.sh
# owner: jlehtone
# group: jlehtone
user::rw-
group::rwx #effective:r--
group:ptest:rwx #effective:r--
mask::r--
other::r--
# file: xxx/file_trans_prlg.sh
# owner: jlehtone
# group: jlehtone
user::rw-
group::rwx #effective:r--
group:ptest:rwx #effective:r--
mask::r--
other::r--
Both files did get the group:ptest:rwx ACL.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.