Linux vs. Windows Persmissions (clients)

  • I just installed a new copy of OMV 1.9 (Kralizec) on all new hardware and enabled the SMB/CIFS service since I'm running a mixed environment of Windows and Linux machines.


    I have a user called "taz" that is a member of a group called "nas-admin" that I'm using to manage the OMV shares. What I've noticed is that the permissions for the directories and files are different depending on whether the files were created on a Linux client or a Windows client. I'm using the same OMV credentials ("taz") when accessing the share either through Windows or Linux.


    For example, here are the permissions as seen from the OMV CLI:
    drwxr-s---+ 2 taz users 4096 Mar 28 18:13 Linux
    drwxrws--x+ 2 taz users 4096 Mar 28 18:13 Windows


    Here is the file ACL values for the Linux directory:


    Here's the file ACL for the Windows directory:


    Here are the file permissions for the Linux and Windows files repsectively:
    -rwxr-x---+ 1 taz users 0 Mar 28 18:20 EmptyDoc.txt
    -rwxrwx---+ 1 taz users 0 Mar 28 18:21 EmptyDoc.txt


    Here is the file ACL values for the Linux file:

    Code
    # file: Linux/EmptyDoc.txt
    # owner: taz
    # group: users
    user::rwx
    user:taz:rwx #effective:r-x
    group::rw- #effective:r--
    group:nas-admin:rwx #effective:r-x
    group:nas-users:r-x
    mask::r-x
    other::---


    Here is the file ACL values for the Windows file:

    Code
    # file: Windows/EmptyDoc.txt
    # owner: taz
    # group: users
    user::rwx
    user:taz:rwx
    group::rw-
    group:nas-admin:rwx
    group:nas-users:r-x
    mask::rwx
    other::---


    The file permissions and ACL values seen for the directory and file created under the Linux environment are correct in the way the ACL is configured for the share.


    Based on my understanding, regardless of the client, the directories/files created would have the same permissions. Why are the files created in the Windows environment allowing file write access to the group and execute access to "others" for the directory?

  • The difference is the mask. I would guess that maybe the Linux application used to create the file has another default mask setting.


    You could try adding this to the /etc/default/openmediavault and see if it makes any difference.

    Bash
    # Samba
    OMV_SAMBA_SHARE_CREATEMASK="0777"
    OMV_SAMBA_SHARE_DIRECTORYMASK="0777"


    To apply the changes run:

    Bash
    omv-mkconf samba
    service samba restart
  • You could try adding this to the /etc/default/openmediavault and see if it makes any difference.
    Shell-Script


    # Samba
    OMV_SAMBA_SHARE_CREATEMASK="0777"
    OMV_SAMBA_SHARE_DIRECTORYMASK="0777"


    First, instead of 0, shouldn't it be 2?! At least the DIRECTORYMASK should have it, shouldn't it?


    And also, shouldn't it be OMV_SAMBA_SHARE_CREATEMASK="2666", or is the CREATEMASK not meant for Files ?


    Greetings
    David

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"


    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!


    I host parts of the omv-extras.org Repository, the OpenMediaVault Live Demo and the pre-built PXE Images. If you want you can take part and help covering the costs by having a look at my profile page.

  • First, instead of 0, shouldn't it be 2?! At least the DIRECTORYMASK should have it, shouldn't it?


    And also, shouldn't it be OMV_SAMBA_SHARE_CREATEMASK="2666", or is the CREATEMASK not meant for Files ?


    Greetings
    David


    I've only changed from the defaults which are:

    Bash
    OMV_SAMBA_SHARE_CREATEMASK=${OMV_SAMBA_SHARE_CREATEMASK:-"0755"}
    OMV_SAMBA_SHARE_DIRECTORYMASK=${OMV_SAMBA_SHARE_DIRECTORYMASK:-"0755"}


    I don't think you need to set the setgid bit from what I've experienced so far. But I've never tested with it set. I think it works without it since the shared folder already has the setgid bit set. The difference when adding the setgid bit would be, and I'm guessing, that it would forced(?). I don't want to force it, but someone else might though so it's good to know.


    I don't see why you would like to limit files to 666 though in normal cases. Because even though you have the drives mounted with noexec you may want to store files with the executable bit set. But each to their own. :)


    The reason I had to use those overrides is because ACLs doesn't work properly otherwise. For example, if you have a group and set rw permissions on a shared folder for that group, the mask of 755 will always strip the write permission for all groups. In the end you have something that doesn't work as expected.

  • That's not sticky bit is setgid. In this case for smb it doesn't matter. The group ownership then will be preserved from the top folder down, this in case the share was created in the webUI of course.


    Haha, I don't know why I confused the two. I've edited the post to be correct since it was setgid I meant. Thanks! :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!