How to configure permissions correctly?

  • At the moment I'am trying to move my files from my old Synology NAS to my new OMV. I have already copied all my files via rsync and I'am now trying to fix the permissions because everthing is 777 atm.


    To determine which permissions are needed by OMV i created a test folder and simply set the permissions accordingly (775 for folders and 644 for files (getting rid of execute for the owner); the share itself has 2775). So far so good.
    But I ran into several problems after this and I guess some of them are bugs (I'am talking about smb only):

    • If there are two users with r/w privileges in OMV(set under shared-folders->privileges), I cannot write to a file that the other user has created. E.g.: user1 creates a file in share test, user2 opens the file in share test, adds something to it and tries to save it -> permission denied. I guess that should not happen. I tried to figure out the cause and I guess its because every file has 644 as permissions where it should be 664 (every file created via smb gets 644 as default). Its the smae with directories, If user1 creates a directory, user2 cant create files in it.
    • The next issue I encountered was that OMV does not restart the smb service in order to apply newly set permissions in the rights-management interface (the yellow bar shows up but after clicking apply everthing stays the same for the smb client, in OMV everything is updated but its not applied). After manually restarting the smb service everthing is working correctly as set in the gui. So I guess there is a missing reload.

    I hope you can help me setting these things up correctly.

  • If there are two users with r/w privileges in OMV(set under shared-folders->privileges), I cannot write to a file that the other user has created. E.g.: user1 creates a file in share test, user2 opens the file in share test, adds something to it and tries to save it -> permission denied. I guess that should not happen. I tried to figure out the cause and I guess its because every file has 644 as permissions where it should be 664 (every file created via smb gets 644 as default). Its the smae with directories, If user1 creates a directory, user2 cant create files in it.


    You can request a fix for that on the bugtracker, I'm not sure if you can set the for directory mask (and file mask) via the extra options.


    The next issue I encountered was that OMV does not restart the smb service in order to apply newly set permissions in the rights-management interface (the yellow bar shows up but after clicking apply everthing stays the same for the smb client, in OMV everything is updated but its not applied). After manually restarting the smb service everthing is working correctly as set in the gui. So I guess there is a missing reload.


    It should restart the samba service when you apply the config changes already.


    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!

  • If you have a folder that you want users to be able to write you should just use chmod 775. The data disks are not executable and this is the default chmod when a folder is created. So if you have a folder you want to fix recursively:


    change directory to one level above the folder
    chmod -R 775 foldername
    chown -R root:users foldername


    for stuff with the web-gui you need to refresh the browser for a lot of things.

  • If you have a folder that you want users to be able to write you should just use chmod 775. The data disks are not executable and this is the default chmod when a folder is created. So if you have a folder you want to fix recursively:


    change directory to one level above the folder
    chmod -R 775 foldername


    I already know that 775 would fix my problems but every new directory or file would be created with false permissions so it would be only a temporary solution. And somehow all new files I create get 744 instead of 644 via smb. Here is the share, files and folder I created for testing, everthing is untouched and only created using OMV-gui for the share and a Windows client for the files and folder:

    Code
    anon1@sirius:/media/52bf6400-6edf-4136-9a3d-5d0e815994ee/test$ ls -lah
    total 16K
    drwxrwsr-x 3 root   users 4.0K Sep 23 01:17 .
    drwxr-xr-x 8 root   root  4.0K Sep 22 18:20 ..
    drwxr-sr-x 2 anon2 users 4.0K Sep 22 21:05 Neuer Ordner
    -rwxr--r-- 1 anon2 users    0 Sep 22 18:23 Neues Textdokument (2).txt
    -rwxr--r-- 1 anon2 users    0 Sep 22 20:29 Neues Textdokument (3).txt
    -rwxr--r-- 1 anon3 users    0 Sep 22 20:50 Neues Textdokument (4).txt
    -rwxr--r-- 1 anon2 users    0 Sep 23 01:17 Neues Textdokument (5).txt
    -rwxr--r-- 1 anon2 users    9 Sep 22 20:22 Neues Textdokument.txt


    This is the share definition in /etc/samba/smb.conf:


    Also the better way to "fix" something like this would be

    Code
    find /path/to/base/dir -type d -print0 | xargs -0 chmod 755 
    find /path/to/base/dir -type f -print0 | xargs -0 chmod 644


    because otherwise files would get exec permissions when using -R switch on chmod.

  • der_Typ schrieb:
    If there are two users with r/w privileges in OMV(set under shared-folders->privileges), I cannot write to a file that the other user has created. E.g.: user1 creates a file in share test, user2 opens the file in share test, adds something to it and tries to save it -> permission denied. I guess that should not happen. I tried to figure out the cause and I guess its because every file has 644 as permissions where it should be 664 (every file created via smb gets 644 as default). Its the smae with directories, If user1 creates a directory, user2 cant create files in it.




    You can request a fix for that on the bugtracker, I'm not sure if you can set the for directory mask (and file mask) via the extra options.


    Thanks, I just did http://bugtracker.openmediavault.org/view.php?id=1116.


    It should restart the samba service when you apply the config changes already.


    At least on my system it does not . I have to do it manually. Just to clarify I'am only changing the privileges in "Access-Rights-Mangement"->"Shared Folders" nothing else. After clicking apply the smb service is not restarted and the changed permissions are not active

  • because otherwise files would get exec permissions when using -R switch on chmod.


    Right, but irrelevant since the filesystem is mounted with the noexec option, but maybe not the clean way to do it.


    At least on my system it does not . I have to do it manually. Just to clarify I'am only changing the privileges in "Access-Rights-Mangement"->"Shared Folders" nothing else. After clicking apply the smb service is not restarted and the changed permissions are not active


    Well... my Windows machine does not recognize permission changes until a reboot. Even if I restart Samba manually.


    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!

  • Well... my Windows machine does not recognize permission changes until a reboot. Even if I restart Samba manually.


    Is there a way to check if OMV is reloading the config or restarting the service? I don't see anything in the syslog, but i dont know if OMV does a reload or a restart (I guess a restart would be visible in the syslog).


    On Windows the permissions are updated when I restart samba on the server. I don't know if a reload of the config would require a clientside reconnect to take effect.

  • When you created your shared folder you chose wrong drop down. No that is not it. With Samaba Volker was more restrictive. He did not want owner's files being deleted by another user via SAMABA. If you want it different than default you need to change manually in the smb.conf.


    You are wrong about execute permissions. The data drives are mounted noexec. So even if it is executable it will not be allowed. Look at the mounts in fstab. You will see noexec.

  • What I said there does not apply. I explained in following sentences. It is very important what you choose with the drop down and if you read the description it is pretty obvious what you should choose. But then the Samba is another thing. By the smb.conf it is obvious Volker did not want non-owners (users) of a file/folder deleting the owner's files/folders.

  • It is very important what you choose with the drop down and if you read the description it is pretty obvious what you should choose


    As I understand it this is just the initial chmod for the folder at system level. So I could change this easily after the creation. And the default (admin:rwx; user:rw, others:r) seems ok for me.

    What I said there does not apply. I explained in following sentences. It is very important what you choose with the drop down and if you read the description it is pretty obvious what you should choose. But then the Samba is another thing. By the smb.conf it is obvious Volker did not want non-owners of a file/folder deleting the owner's files/folders.


    Ok thanks now I understand why it is handled this way. But to prevent the deletion of files of other users the "sticky bit" would be a better option because it prevents the deletion but not writing to the files.


    Edit:
    Sorry, the sticky bit would only prevent deletion of files which have the same owner as the directory.
    I think that the current solution in protecting the userfiles is very counterproductive in a multiuser/client environment. For example I have two smb users because one user needs more shares and rights than the other, but some shares are used by programs that both users need to use. In the current setup absolutely no collaboration is possible. For me this would be unacceptable. There should be at least an option to disable this "feature".

  • Yes, the shared folder creation is the system level chmod.



    On 2nd part, it is way Volker did it for some minimal security in the smb.conf. You are free to edit that file for your individual shares to allow chmod you would like.


    PS- There are a million different scenarios you can setup with SAMBA. So when you create something like OMV you have to try a make best decisions that would suite the majority of users. Decisions have to be made in plugins all the time too.

  • On 2nd part, it is way Volker did it for some minimal security in the smb.conf. You are free to edit that file for your individual shares to allow chmod you would like.


    In my opinion this is breaking much more than it helps for security. Also this brings inconsistencies in the configuration because if I set the read/write privilege for two users I expect that both users can read and write to all files in the share, but thats not the case (and its not documented). For me network shares are for collaboration between users, but the current default somehow assumes a one client scenario. The simplest way to improve this would be a checkbox to disable this or enable if you want this protection.


    Do you know if OMV will revert my changes if I change the samba configuration in the gui ?



    PS- There are a million different scenarios you can setup with SAMBA. So when you create something like OMV you have to try a make best decisions that would suite the majority of users. Decisions have to be made in plugins all the time too.


    I totally understand this decisions but such undocumented assumptions make it really hard to get everything working (even harder if you migrate from different systems like Synology or a Windows Server).

  • In an office scenario say a co-worker made an edit I did not like to a file and my original was gone, I would be f'kin pissed. The other users can grab a copy of the file and edit it and save a new copy. I do not see how this is contrary towards productivity. This is my opinion and many people's opinions can vary.


    Edits to your shares on the the smb.conf will not be reverted unless you edit/delte the share in the smb/cifs, which is unlikely. They are pretty static once you create them.


    On documentation, it would be nice if we had documentation for everything. I love to read manuals and I can understand this. But you have to realize that OMV has developed so fast in the last 2 years we would be editing the documentation constantly. There have been videos made by some mods and they are worthless now because of changes. At some point in the next year maybe we can get someone to start on this project.


    I agree with your last point. I have to read through code a lot to figure out what is going on. An end user cannot do what I can do. We know. We try our best and all time by people involved is donated. Very few people have tried to accomplish big things. We are always here on the forums to try and answer your questions.

  • In an office scenario say a co-worker made an edit I did not like to a file and my original was gone, I would be f'kin pissed. The other users can grab a copy of the file and edit it and save a new copy. I do not see how this is contrary towards productivity. This is my opinion and many people's opinions can vary.


    Offices is a completely different environment and hard to compare. Normally in a bigger office this would be achieved via acls on Windows machines and probably shadowcopy. But I always set my environment up in a way that there are shares specific to users (like his documents) where only he has access or maybe some other user read access, and a share for collaboration where everything else is stored that both users need. Because otherwise it would not make much sense to even have the possibility to assign more than one user r/w privileges. But I understand this decision and would welcome a checkbox to disable it per share instead of editing my smb.conf.

    Edits to your shares on the the smb.conf will not be reverted unless you edit/delte the share in the smb/cifs, which is unlikely. They are pretty static once you create them.


    Thanks, then i will do it manually.


    On documentation, it would be nice if we had documentation for everything. I love to read manuals and I can understand this. But you have to realize that OMV has developed so fast in the last 2 years we would be editing the documentation constantly. There have been videos made by some mods and they are worthless now because of changes. At some point in the next year maybe we can get someone to start on this project.


    Maybe I was a little bit inaccurate with what I meant. I was actually thinking about a small text somewhere in the share-creation-dialog like "Attention: Only the owner can edit and delete the file even if r/w permissions are set for another user". But I'am not very good at these kind of texts ;) .
    I totally understand that a rapidly growing project is hard to manage and keep updated especially with only one major developer and I'am impressed how well thought out OMV seems to be for such a small team.


    We try our best and all time by people involved is donated. Very few people have tried to accomplish big things. We are always here on the forums to try and answer your questions.


    I'am really happy about that fact and I really appreciate the extremely good support here on the forums.

  • I did a new installation of omv 1.0 (I was using omv 0.4 until today). I also stumbled over the permissions when using a share for multiple users.


    Actually I have to agree with der_Typ. Why do we have "groups", "privileges" and "acl" when we are forcing the share to 0755/0644? That makes no sense. Effectively it doesn't make sense to use groups, privileges and acl for samba shares anymore!


    Talking about an office... it seems that 0755/0644 imitates the functionality of a browsable "home share".
    Sorry, but I don't get the point why this new "feature" does improve security.

    • Offizieller Beitrag

    If you don't give someone privileges to a samba share, it doesn't matter what the permissions are. Groups are for when you add more groups not to change system groups. I don't understand the need to change system groups/users. The permissions aren't always 0755/0644 either. You pick the permissions when you create the shared folder.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • In the present default configuration of a smb share the permissions for every new file that is created in that share via smb are 755/644. You can only change the permissions of the share itself when you create it. At least thats how I understand and experienced it.


    This is because every share in the smb.conf is created with the following masks:

    Code
    create mask = 0755
    force create mode = 0644
    directory mask = 0755
    force directory mode = 0755
  • I received an answer in the bugtracking system where Volker describes the following solution (which is at least for me the best solution possible):



    After changing these variables every new share and all existing shares use the (for me) correct permissions. The 2nd issue I described in my first post is actually Windows related. OMV seems to do a reload of the samba configuration and therefore the connection to the clients is not interrupted. Active connections are not affected when permissions change, after a clientside reconnect everything works as expected.
    I'm marking this thread as solved, thanks again for the exceptional support in the forum and bugtracker :thumbup:

Jetzt mitmachen!

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