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.

Zitat von tekkbebe

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:

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:

[test]
path = /media/52bf6400-6edf-4136-9a3d-5d0e815994ee/test/
guest ok = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
printable = no
create mask = 0755
force create mode = 0644
directory mask = 0755
force directory mode = 0755
hide dot files = yes
valid users = "anon3","anon2"
invalid users =
read list =
write list = "anon3","anon2"

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

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.

Zitat von davidh2k

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.

Zitat von davidh2k

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

Zitat von davidh2k

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.

Zitat von tekkbebe

When you created your shared folder you chose wrong drop down.

I assume you are talking about the permissions dropdown.
I did only choose the path via dropdown as I thought that the defaut values for the permissions were right? So what would be the right dropdown to choose?

Zitat von tekkbebe

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.

Zitat von tekkbebe

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".

Zitat von tekkbebe

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 ?

Zitat von tekkbebe

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).

Zitat von tekkb

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.

Zitat von tekkb

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.

Zitat von tekkb

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.

Zitat von tekkb

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.

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:

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):

Zitat von votdev

You can define some environment variable in /etc/default/openmediavault to customize the smb.conf to your requirements.

The variables are:

OMV_SAMBA_SHARE_CREATEMASK

OMV_SAMBA_SHARE_FORCECREATEMODE

OMV_SAMBA_SHARE_DIRECTORYMASK

OMV_SAMBA_SHARE_FORCEDIRECTORYMODE

e.g.

OMV_SAMBA_SHARE_CREATEMASK="775"

After modifying /etc/default/openmediavault you have to recreate the smb.conf file with

# omv-mkconf samba

Alles anzeigen

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