cifs mount folder write permission to other users in same group

[Martin Viehoff]

Hallo,

Alt-F 0.1RC4 on DNS-323

Trying to share a folder via smb to users in a group. The users in this group should all have write permissions to all new generated folders and files.

so what i have on the NAS:

Users in group "steiner"

Shared folders see images...

1. User access the share via Linux nautilus and make a new folder "test1" inside the Games folder

smb://192.168.1.50/Publics/Games

Everything works fine and the new folder "test1" is generated with this permissions: rwxrwsr-x (see image 1)

So other users in group steiner could r/w this folder. Perfect!

2. User access the share via fstab cifs mount and make a new folder "test2"

line in fstab:

//192.168.1.50/Publics/Games /media/NAS-SteinerHome-Public cifs sec=ntlm,noauto,users,credentials=/home/dahoff/.smbcredentials_steinerhome 0 0

The new folder "test2" do not get the permissions for group writing: rwxr-sr-x

So all other useres in group "steiner" could not modify the new items.

So do i have a mistake in my share?

Thank you very much for help!

  

[João Cardoso]

I can reproduce that.

The difference is that in 1 you are directly using the samba server running in the NAS, while in 2 you are using the kernel to do the mount and do the file/dirs operations.

So it seems that the mount is ignoring the "inherit permissions" set in the server for the share and the set-group-ID in the share parent's directory? and 'umask' (at the mount client) doesn't seems to affect this.

If you manage to get this uncovered please report back.

Notice that the samba server built in the firmware does not has ACL support, only the Alt-F disk-installable samba package has (this is not the issue, it's just for you to be aware)

Excerpt of the mount.cifs manual page:

FILE AND DIRECTORY OWNERSHIP AND PERMISSIONS

       The core CIFS protocol does not provide unix ownership information or mode for files and

       directories. Because of this, files and directories will generally appear to be owned by

       whatever values the uid= or gid= options are set, and will have permissions set to the default

       file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will

       return success but have no effect.

       When the client and server negotiate unix extensions, files and directories will be assigned

       the uid, gid, and mode provided by the server. Because CIFS mounts are generally single-user,

       and the same credentials are used no matter what user accesses the mount, newly created files

       and directories will generally be given ownership corresponding to whatever credentials were

       used to mount the share.

       If the uid´s and gid´s being used do not match on the client and server, the forceuid and

       forcegid options may be helpful. Note however, that there is no corresponding option to

       override the mode. Permissions assigned to a file when forceuid or forcegid are in effect may

       not reflect the the real permissions.

       When unix extensions are not negotiated, it´s also possible to emulate them locally on the

       server using the "dynperm" mount option. When this mount option is in effect, newly created

       files and directories will receive what appear to be proper permissions. These permissions are

       not stored on the server however and can disappear at any time in the future (subject to the

       whims of the kernel flushing out the inode cache). In general, this mount option is

       discouraged.

       It´s also possible to override permission checking on the client altogether via the noperm

       option. Server-side permission checks cannot be overriden. The permission checks done by the

       server will always correspond to the credentials used to mount the share, and not necessarily

       to the user who is accessing the share.