How to set the exact permissions for a user to RW files and directories to a samba share?

  • I've been trying to set up the right permissions/ACLs on a Samba share to receive files I'm backing up from my phone, which should be straightforward enough... However, none of the configurations I've tried so far allow me consistent access or writing ability. I've managed to access and write files to existing folders on the share, but when I copy a newly created directory from my phone, Samba gives me a STATUS_ACCESS_DENIED error. I've typically managed to bypass this by modifying the ACL to grant recursive read-write access, but this hasn't helped when transferring a new directory later. I checked out this guide Privileges and permissions explained under OMV but the results I'm getting don't match what I'd expect from a Linux system. I've tested giving read-write permissions and ACLs to the user's group, but the results have been inconsistent. My main aim is to allow a user/group to read-write files and directories on a Samba share mainly designated for that user/group. How can I achieve this? Even when I've granted read-write permissions and ACLs to the user's group, testing the credentials using smbclient on Linux doesn't work as expected. It's quite frustrating. I'm pretty sure that I'm missing a crucial step, like, do I need to also modify the filesystem rights? (I have given the user's group rw rights via the ACL screen, didn't help either). Below is the smb config, inherited acls was disabled by default but I enabled it to see if it helped but it didn't.


    ls -al output from directory the share points to.


    M9LLgeW.png



    DzR7VHW.png

    5qVU8HV.png

  • The general advice about ACLs is to avoid them. You can probably can do what you want by using standard linux permissions alone. What app are you using on your (andriod?) mobile phone? Typically they ask for the server (OMV in this case) Ip or hostname, shared folder name, username, and password. The "username" needs to be one of your named accounts added on OMV. If you had created and shared a folder on OMV with the default "Administrator: read/write, Users: read/write, Others: read-only" perms that should suffice. Then give the named user on OMV read/write perms for that folder using the "Storage | Shared Folders | Permissions" tab. Your SMB/CIFS share for that folder can then use the default settings.


    Your listing output only shows ACLS are in use ( indicated by the "+" in the first column) but not what those ACLs are, nor what "effective" rights might result from any mask or default mask that may be set. You need to use the "getfacl" command on the shared folder path to see that ( see: https://www.computerhope.com/unix/ugetfacl.htm ).

    • Offizieller Beitrag

    I've been trying to set up the right permissions/ACLs on a Samba share to receive files I'm backing up from my phone, which should be straightforward enough...

    Android permissions could interfere with your purpose. I would use Syncthing to sync folders from your smartphone to your server. Syncthing has a configuration option that solves this problem with one click.


  • If you had created and shared a folder on OMV with the default "Administrator: read/write, Users: read/write, Others: read-only" perms that should suffice. Then give the named user on OMV read/write perms for that folder using the "Storage | Shared Folders | Permissions" tab. Your SMB/CIFS share for that folder can then use the default settings.

    I will try that but I don't get it though: if I'm assigning that folder to the group that the user belongs to, even at the fs level, why is the user still not able to access the share when I grant it either permissions or acl rw rights?


    getfacl output below:

    getfacl: Removing leading '/' from absolute path names

    # file: srv/mergerfs/storage/backups/phone/Backup Folder

    # owner: root

    # group: phone

    user::rwx

    user:filebrowser:rwx

    group::rw-

    group:appuser:rwx

    group:phone:rwx

    mask::rwx

    other::---

    default:user::rwx

    default:user:filebrowser:rwx

    default:group::rw-

    default:group:appuser:rwx

    default:group:phone:rwx

    default:mask::rwx

    default:other::---


    getfacl: Removing leading '/' from absolute path names

    # file: srv/mergerfs/storage/backups/phone/

    # owner: root

    # group: phone

    # flags: -s-

    user::rwx

    user:filebrowser:rwx

    group::rw-

    group:appuser:rwx

    group:phone:rwx

    mask::rwx

    other::---

    default:user::rwx

    default:user:filebrowser:rwx

    default:group::rw-

    default:group:appuser:rwx

    default:group:phone:rwx

    default:mask::rwx

    default:other::---

  • Android permissions could interfere with your purpose. I would use Syncthing to sync folders from your smartphone to your server. Syncthing has a configuration option that solves this problem with one click.


    Thanks but this permissions/acl stuff has kind of bothered me for a while so I want to figure it out before adding another tool as a workaround to the mix (I know syncthing is a solution in its own right so I'll test it out in the future).

    • Offizieller Beitrag

    this permissions/acl stuff has kind of bothered me for a while so I want to figure it out before

    Well, as Krisbee already told you, it is preferable to avoid ACL permissions if they are not absolutely necessary.


    About permissions in OMV you can consult this document. https://wiki.omv-extras.org/do…misc_docs:nas_permissions


    This post could be helpful too. RE: Cannot access ACL for new shared folder


    If you need to reset the permissions of a shared folder you can use the openmediavault-resetperms plugin https://wiki.omv-extras.org/do…6:omv6_plugins:resetperms


  • Your ALCs look a little odd in the that folder owner group is "phone" but you've also added an ACL for the named group "phone". What's happened to "s" flag (setguid) on the folder /srv/mergerfs/storage/backups/phone/Backup? The other side of this is the samba share config. The quickest way to see a given share's smb/cifs config is to use this command at the CLI: "testparm -s".



    Assuming the ALCs were corrected, in smb/cifs you need to give one or more groups write permission to given shared folders and tick inherit ALCs together with possibly ticking inherit permissions and type "map acl inherit = yes" as an extra option.


    If you want to see which users are connected to your OMV samba server go to Diagnostics | Services | SMB/CIFS


    Lastly as chente andriod file perms could be a problem. I don't have any andriod devices to confirm if this is true or not.

  • Your ALCs look a little odd in the that folder owner group is "phone" but you've also added an ACL for the named group "phone". What's happened to "s" flag (setguid) on the folder /srv/mergerfs/storage/backups/phone/Backup?

    I've added the group to the ACL because users in the phone group were not being able to access the share anyways and I was trying to get around it. I'm not sure I understand your second question regarding setguid, could you exlain/.

  • Looking at the getfacl output for "/srv/mergerfs/storage/backups/phone/" if you subtract the ACLs, the standard perms had owner group perms rw- . In other words, the owner group "phone" could neither traverse or enter the "phone" directory. I would have expected that "Backup" folder to still have setguid.


    Before you even think about using ACL, be clear about how OMV uses standard linux perms in the filesystem layer and the idea of "permissions" (previously called "privileges") in the SAMBA layer. It's explained in the first ref you quoted. Additionally, something which his not visible in the WebUI is actual smb config of individual folder shares. In the background it's a this example for a non-public share with the default shared folder perms:



    Those SAMBA perms/privileges turn into read/write/valid user list ( see: https://docs.openmediavault.or…ation/services/samba.html ) but it also uses a set of mask and mode that match the default shared folder perms.


    Adding ACLs to this framework complicates things. Controlling access via multiple group membership might be OK in Windows where you expect all apps to obey the security model, but it gets messy in linux. Can you be sure all the apps you use, even those directly in OMV are ACL aware? Now add in the translation of the linux filesystem via the SAMBA server into a windows compatible filesystem and you need to know what share options should or not be set. Don't forget that linux based OMV only supports what are called POSIX.1e ACLs which are NOT the same as Windows ACL . While you can view the perms on a share accessed in Windows via the property/security tab you should never try to to amend them from the Windows side, the result can be unpredictable.


    But of course you are not even trying to mount and access a smb share in windows which is why chente pointed to another way of transferring data from phone to OMV. Doing this on a local trusted network is one thing, but over a public network security is all important.

    • Offizieller Beitrag

    chente pointed to another way of transferring data from phone to OMV. Doing this on a local trusted network is one thing, but over a public network security is all important.

    You're right. Remote connections should be avoided if they are not completely necessary, and in that case ensure that they are fully protected.

    Syncthing allows connections over the internet through its own system. It is a mature and theoretically safe application. However, Syncthing also allows you to configure only local connections and that is what I do. My smartphone only syncs when it is connected to the local network. That meets my needs.

  • Before you even think about using ACL, be clear about how OMV uses standard linux perms in the filesystem layer and the idea of "permissions" (previously called "privileges") in the SAMBA layer. It's explained in the first ref you quoted. Additionally, something which his not visible in the WebUI is actual smb config of individual folder shares. In the background it's a this example for a non-public share with the default shared folder perms:

    I will stop using ACLs and I cleared all of them on that share using the reset-permissions plugin, again I simply relied on them because for a while it seemed to be producing the result I expected but if I can simply ignore that section and get the same results then that's even better. I went through the document chente posted https://wiki.omv-extras.org/do…misc_docs:nas_permissions a, this thread Permission problems but also judging by what you all said here OMV starts to behave finicky when we change these permissions and I'm fine with that but then what is the OMV recommended way of setting up a samba share for which only one user or group (besides users) has read/write access? As of now I can think of going to the permissions tab and hitting NO ACCESS on all others, is that the only way?


    Edit: btw I have not changed the samba shares settings manually, everything's been done via the OMV workspace.

  • Access via group membership offers greater flexibility.


    1. Create your new group, e.g. "phoneuser" and add one or more named users to the group.


    2. Create a shared shared folder with default perms. Go to the ACL tab for that shared folder. Use only the bottom half of the screen to change the default standard linux perms by selecting the new "phone" group instead of "users". Leave group and owner perms at rwx. Change "others" to none if you wish.


    3. Go to your new group "phoneuser" in "user Management" and select "shared folder permissions" and give the group "read/write" perms on the folder ( this will create a write list for the group in the smb config for that shared folder).


    4. Create a SMB share for the folder, the default settings should suffice.


    5. Test access from Windows.


    Under the hood you'd have for the example group "phoneuser", a smb config of:




    and shared folder perms of:


    Code
    root@omvtest:~# ls -ld /srv/dev-disk-by-uuid-e08eb6e6-e84b-4845-848a-bdceb1b9d9c1/phonedata/
    
    drwxrwsr-x+ 3 root phoneuser 4096 Jan  2 09:29 /srv/dev-disk-by-uuid-e08eb6e6-e84b-4845-848a-bdceb1b9d9c1/phonedata/


    Why the "+"? A by-product of using the ACL tab on a shared folder to change only the standard linux perms is a default ACL, which you can regard as noise in this case.


    • Offizieller Beitrag

    what is the OMV recommended way of setting up a samba share for which only one user or group (besides users) has read/write access?

    That's the least intrusive way to do it and the one I would recommend. Simply edit the permissions of that shared folder and grant permissions to the user/group you need and deny access to the rest of the users/groups.

    That way you do not modify ACL permissions or file-level permissions, you only configure access permissions through the service, obtaining the result you want. That is, the files and folders will continue to have standard OMV permissions and there will be no ACL permissions, but only the user you want can access them.


    is that the only way?

    You can do it using ACL too but I wouldn't recommend it, in this case you don't need it.

    As you will have seen if you have read all the links and everything that has been said in this thread, there are many ways to manage permissions in Linux.

  • 2. Create a shared shared folder with default perms. Go to the ACL tab for that shared folder. Use only the bottom half of the screen to change the default standard linux perms by selecting the new "phone" group instead of "users". Leave group and owner perms at rwx. Change "others" to none if you wish.

    Seems to work, one thing though, why if I give only rw rights to the group instead of rwx the user doesn't seem to even be able to read the contents of the share? :/

    • Offizieller Beitrag

    You might try setting:

    - The Shared Folder; Others - Read/Write/Execute

    - The SMB share; Public - Guests Allowed


    That's wide open permissions. Work from there.

    The problem may not, necessarily, be with Samba. The client (a phone in this case) is a factor as well.

  • Seems to work, one thing though, why if I give only rw rights to the group instead of rwx the user doesn't seem to even be able to read the contents of the share? :/

    OK. Good to hear things are working now. You're talking about about folder/directory permissions where the "x" means "traverse or enter" a folder/directory. For a file it means "execute". As you are granting read/write access to the folder by virtue of group membership - you need "rwx" not "rw".

  • OK. Good to hear things are working now. You're talking about about folder/directory permissions where the "x" means "traverse or enter" a folder/directory. For a file it means "execute". As you are granting read/write access to the folder by virtue of group membership - you need "rwx" not "rw".

    🤯 I definitely was not aware of that distinction. Thanks for your patience in this thread, I think I now do have a better handle on this and getting the expected behavior.

  • 🤯 I definitely was not aware of that distinction. Thanks for your patience in this thread, I think I now do have a better handle on this and getting the expected behavior.

    A couple of refs if you ever need a reminder of the basics:


    Classic SysAdmin: Understanding Linux File Permissions - Linux Foundation
    Although there are already a lot of good security features built into Linux-based systems, one very important potential vulnerability can exist when local…
    www.linuxfoundation.org

    An Introduction to Linux Permissions | DigitalOcean

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!