Samba and permissions

[SpaceGhostC2C]

So, I'm setting up an Ubuntu server that should host network storage for the rest of the house, where Linux and Windows machines exist. I've created a raidz pool and shared it using Samba, although I haven't messed with the Samba config file at all. Instead, I just added my user to Samba (smbpasswd -a <user>), and changed ownership in the root folder of the storage pool (with -R) to the group "sambashare". I changed permissions to 770, as everyone in "sambashare" should have full access, whereas anyone without authentication should have none.

 

From windows, I connected to the shared folder using the password set on the server with smbpasswd and got access as expected. Then I proceeded to copy a bunch of files from the Windows PC to the samba share. It went fine, as far as I can see.

The problem is, the folder I copied (I assume the files within as well) have "owner <user>, group <user>", not "sambashare", and therefore other users with permissions to the main folder cannot write inside the folder I copied. This is not intended behavior: inside the share it should be free for all for any authenticated user that's a member of sambashare. I can change ownership and permissions of those files after the fact, but that's clearly impractical.

 

How should I configure either Linux's permissions or Samba so that anything added to the shared folder and its subfolders, especially when done from client computers, is by default available with full access to all members of "sambashare"?

[Alex Atkin UK]

By default samba will only share a users home directory, so I'm a little confused what share you actually did this on.

 

In order to share a folder for everyone you would need to add a share set with a specific user that it will assign to all files written there.

 

eg:

[public]
    public = yes
    writeable = yes
    force directory mode = 770
    comment = Public Read/Write Drive
    path = /mnt/sharedfolder
    force user = sambashare
    force group = users
    force create mode = 770

 

[SpaceGhostC2C]

45 minutes ago, Alex Atkin UK said:

By default samba will only share a users home directory, so I'm a little confused what share you actually did this on.

Well, now I'm confused too

I've created a zfs pool with 4 HDDs from a live boot USB to test the functionality. Then I installed Ubuntu Server to an SSD, but it had issues, so I took a different USB (Ubuntu MATE) and installed that to the SSD, wiping everything. I then imported the zfs pool and it showed up at /<poolname> as a folder owned by root.

I used the "share options" from the file manager ("Caja") to make /<poolname> shared, but when trying to connect to \\<servername> it rejected my Linux credentials. Completely ignorant about samba, I changed group ownership to "sharesamba" and permissions to members of "sambashare" to rwx, verifying I was a member of "sambashare". Still no access from Windows. I then did smbpasswd -a <username>, set the password, then try again from windows and it went through. All I could see was "\\<servername>\<poolname>", which is what I wanted, but no home folder shared (I wouldn't want that either, so I hope whatever I do next doesn't change that).

smbpasswd is literally the only samba command I ran 

 

45 minutes ago, Alex Atkin UK said:

 

In order to share a folder for everyone you would need to add a share set with a specific user that it will assign to all files written there.

 

eg:

[public]
    public = yes
    writeable = yes
    force directory mode = 770
    comment = Public Read/Write Drive
    path = /mnt/sharedfolder
    force user = sambashare
    force group = users
    force create mode = 770

 

Does it mean that everyone should log in with the same, ad-hoc user when accessing the shared folder from other PCs? Would they have access to it with their local Linux account?

I guess it would work for me as a workaround (although it means we all need to remember an additional username and password).

Thanks, I'll try that!

 

I'm a bit puzzled, though: how would an organization handle network storage that should be accessible to everyone in a group, but not everyone with access to network storage? Something like would expect it to be somehow attached to their individual credentials, rather than having a network-storage-specific credential that group shares (at least that's how it works at my workplace, although I think they have an all-Windows network). 

[Akolyte]

58 minutes ago, SpaceGhostC2C said:

Well, now I'm confused too

I've created a zfs pool with 4 HDDs from a live boot USB to test the functionality. Then I installed Ubuntu Server to an SSD, but it had issues, so I took a different USB (Ubuntu MATE) and installed that to the SSD, wiping everything. I then imported the zfs pool and it showed up at /<poolname> as a folder owned by root.

I used the "share options" from the file manager ("Caja") to make /<poolname> shared, but when trying to connect to \\<servername> it rejected my Linux credentials. Completely ignorant about samba, I changed group ownership to "sharesamba" and permissions to members of "sambashare" to rwx, verifying I was a member of "sambashare". Still no access from Windows. I then did smbpasswd -a <username>, set the password, then try again from windows and it went through. All I could see was "\\<servername>\<poolname>", which is what I wanted, but no home folder shared (I wouldn't want that either, so I hope whatever I do next doesn't change that).

smbpasswd is literally the only samba command I ran 

 

Does it mean that everyone should log in with the same, ad-hoc user when accessing the shared folder from other PCs? Would they have access to it with their local Linux account?

I guess it would work for me as a workaround (although it means we all need to remember an additional username and password).

Thanks, I'll try that!

 

I'm a bit puzzled, though: how would an organization handle network storage that should be accessible to everyone in a group, but not everyone with access to network storage? Something like would expect it to be somehow attached to their individual credentials, rather than having a network-storage-specific credential that group shares (at least that's how it works at my workplace, although I think they have an all-Windows network). 

Hey Mate, 

 

I'm just going to start off by saying I'm by no means a Linux expert and normally avoid answering these kind of questions because I could definitely be wrong, but I feel fairly confident I might know whats up.  Just a disclaimer. 

 

So, if users already have access because they are members of the correct group, but when they create directories/files it is automatically owned by their user, and so when other users would like to access the files they have no permission?  

 

This sounds like an issue that can be resolved with special bits, when editing a umask the linux system, you will notice there are 4 bits and not 3. (0000 not 000, as typically, when setting permissions it's 770 etc). This extra first bit can be used to define a special value for the permissions.  Now, I don't suggest setting a special umask for the entire system as it could cause accessibility issues, 

 

So my suggestion to you, would be to try and change the permissions on the directory you are sharing to 2770.  This should apply the correct bit (the setgid bit) which should make all created files created within the directory to default to the owner of the directory.  

 

So, assuming you have the directory you are sharing set to be owned by the group you are using to control access, setting the setgid bit by adding the 2 before your chmod bits, should resolve your issue. 

[SpaceGhostC2C]

47 minutes ago, Akolyte said:

Hey Mate, 

Hi, and thanks for your reply!

 

Quote

 

So, if users already have access because they are members of the correct group, but when they create directories/files it is automatically owned by their user, and so when other users would like to access the files they have no permission?  

Correct!

Quote

 

This sounds like an issue that can be resolved with special bits, when editing a umask the linux system, you will notice there are 4 bits and not 3. (0000 not 000, as typically, when setting permissions it's 770 etc). This extra first bit can be used to define a special value for the permissions.  Now, I don't suggest setting a special umask for the entire system as it could cause accessibility issues, 

 

So my suggestion to you, would be to try and change the permissions on the directory you are sharing to 2770.  This should apply the correct bit (the setgid bit) which should make all created files created within the directory to default to the owner of the directory.  

This went a long way in the right direction - it works almost exactly like you describe when I create a folder from the server itself (good old mkdir). I say almost because while everything is drwxrws---, the folder I create is drwxrwsr-x. However, a second user in the sambashare group can in fact create further subfolders, so it's also "close enough". However, when creating the folder from the Windows machine, it still creates it as drwxr-sr-x, and the second user cannot create folders inside it 

Everything inside the share folder is owned by username:sambashare, except the outmost folder (/<poolname>) which is owned by root:sambashare.

 

I think in any case I have to re-do the samba thing: when trying to follow @Alex Atkin UK's advice, I could not find my share in smb.conf: it turns out that if you use the GUI file manager to share something, it doesn't write it as a block there, but as a separate file called /var/lib/samba/usershares/<sharename>... And the syntax kind of only partially match? 

(note to Linux devs: yes, every non-linux user complains about "having to use the terminal". But if the way to implement it in GUI is some shortcut that does not replicate what you would do via CLI, cutting them off from the stream of CLI help available online, then it just make things worse in the "linux is too hard!" direction)

 

I also followed some online advice and added "inherit permissions = yes" in the  smb.conf [global] section and restarted samba, to no avail. But at this point I think my smb.conf is maybe being ignored/overridden by some other file like the /var/lib one, so I may stop the current share and remake it through smb.conf with @Alex Atkin UK's suggestion, or some variant of it (maybe I'll start forcing groups and permissions only, and see if I can get away not forcing user).

 

Odd thing, it is enforcing the correct group ownership (before it was user:user, now it's user:sambashare), but permissions refuse to follow suit.

 

 

 

EDIT: OK, short update - when everything else fails, reboot  Rebooted the server and now folders were created with the right permissions!  Not sure if it was the inherit permissions thing in smb, or the sticky bit in chmod, and not sure if the reboot helped because it restarted samba "for real", or because it forced windows to kill the previous connection and establish a new one under updated smb parameters.

Still, I think it may be worth going back to basics and setting up the samba share the "normal" way, because who knows whether this is the last issue I'll encounter, and I feel having everything in the smb.conf file is a bit more "supported".

[Akolyte]

20 minutes ago, SpaceGhostC2C said:

Hi, and thanks for your reply!

 

Correct!

This went a long way in the right direction - it works almost exactly like you describe when I create a folder from the server itself (good old mkdir). I say almost because while everything is drwxrws---, the folder I create is drwxrwsr-x. However, a second user in the sambashare group can in fact create further subfolders, so it's also "close enough". However, when creating the folder from the Windows machine, it still creates it as drwxr-sr-x, and the second user cannot create folders inside it 

Everything inside the share folder is owned by username:sambashare, except the outmost folder (/<poolname>) which is owned by root:sambashare.

 

I think in any case I have to re-do the samba thing: when trying to follow @Alex Atkin UK's advice, I could not find my share in smb.conf: it turns out that if you use the GUI file manager to share something, it doesn't write it as a block there, but as a separate file called /var/lib/samba/usershares/<sharename>... And the syntax kind of only partially match? 

(note to Linux devs: yes, every non-linux user complains about "having to use the terminal". But if the way to implement it in GUI is some shortcut that does not replicate what you would do via CLI, cutting them off from the stream of CLI help available online, then it just make things worse in the "linux is too hard!" direction)

 

I also followed some online advice and added "inherit permissions = yes" in the  smb.conf [global] section and restarted samba, to no avail. But at this point I think my smb.conf is maybe being ignored/overridden by some other file like the /var/lib one, so I may stop the current share and remake it through smb.conf with @Alex Atkin UK's suggestion, or some variant of it (maybe I'll start forcing groups and permissions only, and see if I can get away not forcing user).

 

Odd thing, it is enforcing the correct group ownership (before it was user:user, now it's user:sambashare), but permissions refuse to follow suit.

It is a bit odd.  I'm glad it was a step in the right direction though. 

 

See if you can re-create the share manually, and see what happens. The configuration file is in another location, so it could be possible, as you said it's being controlled by a file somewhere else on the system. Probably so users can create their own shares that don't interfere with the ones an administrator set-up manually. 

 

Let us know how you go, and don't hesitate to flick me a message or start a post if you run into any more issues.  Here to help! 

[Alex Atkin UK]

14 hours ago, SpaceGhostC2C said:

Does it mean that everyone should log in with the same, ad-hoc user when accessing the shared folder from other PCs? Would they have access to it with their local Linux account?

I guess it would work for me as a workaround (although it means we all need to remember an additional username and password).

Thanks, I'll try that!

 

I'm a bit puzzled, though: how would an organization handle network storage that should be accessible to everyone in a group, but not everyone with access to network storage? Something like would expect it to be somehow attached to their individual credentials, rather than having a network-storage-specific credential that group shares (at least that's how it works at my workplace, although I think they have an all-Windows network). 

You can set public to no and use "valid users" and "write list" to specify the users who have access.

The force options are for permissions, they force all files created to be owned by a single user regardless of who actually logged in.

 

Another example, how I access my test web server:

Quote

[apache]
    delete readonly = yes
    path = /home/apache
    write list = alexatkin
    force directory mode = 775
    force user = apache
    force group = apache
    force create mode = 775

I probably should have permissions 770 there, I'm not exactly focused on super security as there are only two users on the network anyway.