[SOLVED] cifs/smb mounts: how can concurrent users claim ownership of new files on the same mount?

scottmusician · 09-25-2022, 07:12 AM

Hi all,

My workplace has 3x sysadmins, lets call them Bill, Sarah and Leslie.
All 3x admins need to be able to concurrently log into the same linux server, and create new files on a cifs/smb mounted share. Whenever a particular sysadmin creates a new file, we are hoping that this person's name can be recorded as the 'owner' of the new file (and similarly, that their PGID is listed as the 'group' owner for the new file permissions).
For example, when Jed accesses the machine and writes a new file to /mnt/SharedCifsVol , we want the ownership to be Jed. At the same time, we'd like Bill's new files in the same place to be listed as Bill:BillsGroup .

Currently, whenever /mnt/SharedCifsVol gets mounted, whoever mounts the volume ends up with their UID+GID being reported for owner+group (eg. via ls -l).

Is there a relatively simple way (without unmounting / remounting the volume) to make creator = owner regardless of the CIFS credentials? We are mounting with a command that's similar to:

[Bill@Server] $ sudo mount -t cifs -o cache=strict,username=bill,domain=ourcompany,uid=5159,forceuid,gid=100,forcegid,file_mode=0755,dir_m ode=0755,soft,nounix,mapposix,rsize=65536,wsize=65536,echo_interval=60,actimeo=1 //our-fileserver.fqdn-domain.com/SharedCifsVol /mnt/SharedCifsVol

--

additional question: once mounted, would files copied into this share retain original owner:group information? Or would they inherit the credentials of either (a) whoever mounted the volume, or perhaps (b) whoever facilitates the copying?

ferrari · 09-26-2022, 01:28 AM

Quote:

My workplace has 3x sysadmins, lets call them Bill, Sarah and Leslie.
All 3x admins need to be able to concurrently log into the same linux server, and create new files on a cifs/smb mounted share. Whenever a particular sysadmin creates a new file, we are hoping that this person's name can be recorded as the 'owner' of the new file (and similarly, that their PGID is listed as the 'group' owner for the new file permissions).

The working smb.conf for the share would be useful here.

The 'inherit owner' and 'inherit permissions' parameters are important to multi-user access environments. From 'man smb.conf'....

Quote:

inherit owner (S)

The ownership of new files and directories is normally governed by effective uid of the connected user. This option allows the Samba administrator to specify that the ownership for new files and directories should be controlled by the ownership of the parent directory.

Valid options are:

• no − Both the Windows (SID) owner and the UNIX (uid) owner of the file are governed by the identity of the user that created the file.

• windows and unix − The Windows (SID) owner and the UNIX (uid) owner of new files and directories are set to the respective owner of the parent directory.

• yes − a synonym for windows and unix.

• unix only − Only the UNIX owner is set to the UNIX owner of the parent directory.

Common scenarios where this behavior is useful is in implementing drop−boxes, where users can create and edit files but not delete them and ensuring that newly created files in a user's roaming profile directory are actually owned by the user.

The unix only option effectively breaks the tie between the Windows owner of a file and the UNIX owner. As a logical consequence, in this mode, setting the the Windows owner of a file does not modify the UNIX owner. Using this mode should typically be combined with a backing store that can emulate the full NT ACL model without affecting the POSIX permissions, such as the acl_xattr VFS module, coupled with acl_xattr:ignore system acls = yes. This can be used to emulate folder quotas, when files are exposed only via SMB (without UNIX extensions). The UNIX owner of a directory is locally set and inherited by all subdirectories and files, and they all consume the same quota.

Default: inherit owner = no

inherit permissions (S)

The permissions on new files and directories are normally governed by create mask, directory mask, force create mode and force directory mode but the boolean inherit permissions parameter overrides this.

New directories inherit the mode of the parent directory, including bits such as setgid.

New files inherit their read/write bits from the parent directory. Their execute bits continue to be determined by map archive, map hidden and map system as usual.

Note that the setuid bit is never set via inheritance (the code explicitly prohibits this).

This can be particularly useful on large systems with many users, perhaps several thousand, to allow a single [homes] share to be used flexibly by each user.

Default: inherit permissions = no

scottmusician · 10-02-2022, 08:34 PM

just what I was after - thank you!

descendant_command · 10-03-2022, 04:31 AM

I don't think it is (assuming your 3 sysadmins are on the same system, and the cifs
connection is to a remote SMB server).

Each user will need to mount the share with their own credentials, on their own mountpoint.

If Sarah drops a file into Bill's mountpoint, the SMB server will only ever see a file created by bill.billsgroup.