Difference between revisions of "Setting up a Share Using POSIX ACLs"

m (Fix link)
(Major rewrite with more details/examples.)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
Samba allows you, to do most [[Shares_with_Windows_ACLs|share configurations via Windows and using Windows ACLs]]. This is also the recommended way!
+
On every Samba host you can, like on any MS Windows OS, share a folder to make it accessible for other users. There's no difference if this host is an Samba [[Active_Directory_Domain_Controller|Active Directory Domain Controller]], a [[Setup_Samba_as_an_AD_Domain_Member|Domain Member]] or a [[Standalone_server|Standalone server]]. File shares can be setup in two ways: To be [[Shares_with_Windows_ACLs|managed from Windows using Windows tools and ACLs]] or completely via smb.conf parameters and POSIX ACLs. The latter is described in this documentation.
  
But it is also possible to set ACLs directly on the filesystem and define access to the share in the smb.conf share configuration. This guide describes the way of accomplish this.
+
'''Important note:''' Samba Active Directory Domain Controllers have extended ACL support enabled globally, what requires always to [[Shares_with_Windows_ACLs|manage share permissions and ACLs via Windows]]!
  
  
'''Important information:'''
 
  
'''Samba Active Directory Domain Controllers have enabled extended ACL support globally. For this kind of Samba servers, you can't choose this way to setup shares and permissions. See [[Shares_with_Windows_ACLs|Setup and configure file shares with Windows ACLs]] instead.'''
 
  
  
 +
= Execute bit on files =
  
 +
In Samba prior 4.0, the execution bit of files were not checked. This caused that users could execute a file (*.exe, *.bat, etc.) on a share, even if the x-bit was not set. In Samba 4.0 this was fixed and by default, execution is denied, when the x-bit is not set on a file. In some situations, like when upgrading from an older version, your files may not be executable any more. As a <u>workaround</u>, the old behavior can be brought back, by setting the following smb.conf parameter to "true" (globally or per share):
  
 +
acl allow execute always = true
  
= Preparatory work =
+
Anyway we recommend this as a workaround until you have fixed the permissions by adding the x-bit, when files on a share should be executed.
  
It's possible to have a mixed configuration of shares with Windows ACL support and POSIX ACL shares. But in that case, the <u>[[Shares_with_Windows_ACLs#ACL_support_on_member_server|Windows ACL support]] must not be enabled globally</u>!
 
  
  
  
  
 +
= Adding a new share =
  
= Execution of files =
+
* Create a new folder, that should be shared, if it doesn't already exist
  
With Samba 3.6 and older, the execution right in the ACL was not checked. So a user could execute a file, even if he/she did not have execute rights on it. In Samba 4 and later, this has been fixed, so that by default, execution is denied, when the file doesn't have the x-bit set!
+
# mkdir -p /srv/samba/Demo/
  
In some situations, like when upgrading from an older Samba version, your files may haven't the x-Bit set, due to a previous configuration. A <u>workaround</u>, to make *.exe, *.bat, etc. files executable again, is to set
+
* Add a new share to your smb.conf. The following is the required minimum:
  
  acl allow execute always = True
+
  [Demo]
 +
        path = /srv/samba/Demo/
 +
        read only = no
  
in your smb.conf (per share or globally). But rate this as a workaround! You should fix the permissions and add the x-bit for user/group/other, when the file should be executed.
+
* Reload Samba
  
 +
# smbcontrol all reload-config
  
  
  
  
= Adding a new share =
+
= Setup share permissions (optional) =
  
* Create a folder to be shared:
+
Like on MS Windows OS, you can define share permissions, which are validated directly when a user connects to a share. Share permissions are defined on each share individually. Samba needs to be reloaded/restarted, if changes were done.
# mkdir -p /srv/samba/Demo/
 
  
* Add a new share to your smb.conf. The following is the required minimum:
 
[Demo]
 
      path = /srv/samba/Demo/
 
      read only = no
 
  
* Reload Samba:
 
# smbcontrol all reload-config
 
  
= Setup share permissions =
+
== User/group based share access ==
 
 
Share permissions are defined in your servers smb.conf section indiviually for each share. After changes, a reload of Samba is required!
 
 
 
Example:
 
  
 
  [Demo]
 
  [Demo]
         path = /srv/samba/Demo
+
         path = /srv/samba/Demo/
 
         read only = no
 
         read only = no
         valid users = +SAMDOM\DemoGroup
+
         valid users = +SAMDOM\"Domain Users"
         guest ok = no
+
         invalid users = +SAMDOM\"Demo Group" SAMDOM\foobar
  
Explanations:
+
The above example allows only to connect to the "Demo" share, if the user is member of the "Domain Users" group. Member of the "Demo Group" and user "foobar" are not allowed to connect, even if they are part of "Domain Users". Where the lists conflict, the "invalid users" parameter has precedence!
  
path = /srv/samba/Demo
 
# Defines the location of the folder in the local filesystem.
 
  
read only = no
 
# The share is read/write enabled.
 
  
valid users = +SAMDOM\DemoGroup
+
== Host based share access ==
# Only members of this domain group are allowed to access the share.
 
# Filesystem ACLs are not affected by this setting.
 
  
  guest ok = no
+
Contrary to MS Windows hosts, Samba is able to limit the access to a share to a list of IPs, subnets or hostnames.
# It's not allowed to access the share without password (guest account).
+
 
 +
  [Demo]
 +
        path = /srv/samba/Demo
 +
        read only = no
 +
        hosts allow = 127.0.0.1 10.99.0.0/24 GoodHost1
  
This are just a few possible parameters, that can be set on a share. See
+
The above example allows access to the share only if the connection is initiated from 127.0.0.1, the subnet 10.99.0.0/24 or the host with name "GoodHost1". Alternatively it is possible to deny hosts via
  
# man smb.conf
+
        hosts deny = BadHost1
  
for more share parameters and their options.
+
If both parameters (allow/deny) are defined and the lists conflict, the "allow" parameter has precedence! For further information and examples, see the smb.conf man page.  
  
  
Line 86: Line 77:
  
  
= Change permissions on folders of a share =
+
= File system ACLs =
  
Changes of permissions are done using the classic *nix tools 'chmod', 'chown' and 'chgrp'.
+
ACLs on POSIX enabled shares are set using the typical tools: "chmod", "chown" and "chgrp".
  
 
Example:
 
Example:
  
 
  # mkdir /srv/samba/Demo/Example/
 
  # mkdir /srv/samba/Demo/Example/
# chown foobar:DemoGroup /srv/samba/Demo/Example/
 
 
  # chmod 2770 /srv/samba/Demo/Example/
 
  # chmod 2770 /srv/samba/Demo/Example/
 +
# chown foobar:"Demo Group" /srv/samba/Demo/Example/
  
These commands create a new folder 'Example' in the root of the 'Demo' share previously created. The permissions ('2770') define that the user ('foobar') and the group ('DemoGroup') have read/write/execute on the folder. The set-GID-bit defines that all files/folders below this one, inherit the group ('DemoGroup') from the parent folder.
+
These commands create a new folder in the root of the "Demo" share. The permissions (2770) define, that only the owner "foobar" and group "Demo Group" have read/write/execute permissions on the folder. You might have noticed the SGID (setgid) bit was set on the folder. This causes that all files and subfolders that will be created, inherit the group ("Demo Group") instead setting it to the default group of the users doing the creation.
  
  
Line 104: Line 95:
 
= Related documentation =
 
= Related documentation =
  
The following documentation treat topics, related on setting up file shares with special permissions or purposes:
+
The following documentation discusses related topics:
  
* [[User_home_drives|Setting up a home share]]
+
* [[User_home_drives|Setting up home drives]]
  
* [[Implementing_roaming_profiles|Samba and Windows Profiles]]
+
* [[Implementing_roaming_profiles|Implementing Windows roaming profiles]]

Revision as of 17:07, 31 October 2015

Introduction

On every Samba host you can, like on any MS Windows OS, share a folder to make it accessible for other users. There's no difference if this host is an Samba Active Directory Domain Controller, a Domain Member or a Standalone server. File shares can be setup in two ways: To be managed from Windows using Windows tools and ACLs or completely via smb.conf parameters and POSIX ACLs. The latter is described in this documentation.

Important note: Samba Active Directory Domain Controllers have extended ACL support enabled globally, what requires always to manage share permissions and ACLs via Windows!



Execute bit on files

In Samba prior 4.0, the execution bit of files were not checked. This caused that users could execute a file (*.exe, *.bat, etc.) on a share, even if the x-bit was not set. In Samba 4.0 this was fixed and by default, execution is denied, when the x-bit is not set on a file. In some situations, like when upgrading from an older version, your files may not be executable any more. As a workaround, the old behavior can be brought back, by setting the following smb.conf parameter to "true" (globally or per share):

acl allow execute always = true

Anyway we recommend this as a workaround until you have fixed the permissions by adding the x-bit, when files on a share should be executed.



Adding a new share

  • Create a new folder, that should be shared, if it doesn't already exist
# mkdir -p /srv/samba/Demo/
  • Add a new share to your smb.conf. The following is the required minimum:
[Demo]
       path = /srv/samba/Demo/
       read only = no
  • Reload Samba
# smbcontrol all reload-config



Setup share permissions (optional)

Like on MS Windows OS, you can define share permissions, which are validated directly when a user connects to a share. Share permissions are defined on each share individually. Samba needs to be reloaded/restarted, if changes were done.


User/group based share access

[Demo]
       path = /srv/samba/Demo/
       read only = no
       valid users = +SAMDOM\"Domain Users"
       invalid users = +SAMDOM\"Demo Group" SAMDOM\foobar

The above example allows only to connect to the "Demo" share, if the user is member of the "Domain Users" group. Member of the "Demo Group" and user "foobar" are not allowed to connect, even if they are part of "Domain Users". Where the lists conflict, the "invalid users" parameter has precedence!


Host based share access

Contrary to MS Windows hosts, Samba is able to limit the access to a share to a list of IPs, subnets or hostnames.

[Demo]
       path = /srv/samba/Demo
       read only = no
       hosts allow = 127.0.0.1 10.99.0.0/24 GoodHost1

The above example allows access to the share only if the connection is initiated from 127.0.0.1, the subnet 10.99.0.0/24 or the host with name "GoodHost1". Alternatively it is possible to deny hosts via

       hosts deny = BadHost1

If both parameters (allow/deny) are defined and the lists conflict, the "allow" parameter has precedence! For further information and examples, see the smb.conf man page.



File system ACLs

ACLs on POSIX enabled shares are set using the typical tools: "chmod", "chown" and "chgrp".

Example:

# mkdir /srv/samba/Demo/Example/
# chmod 2770 /srv/samba/Demo/Example/
# chown foobar:"Demo Group" /srv/samba/Demo/Example/

These commands create a new folder in the root of the "Demo" share. The permissions (2770) define, that only the owner "foobar" and group "Demo Group" have read/write/execute permissions on the folder. You might have noticed the SGID (setgid) bit was set on the folder. This causes that all files and subfolders that will be created, inherit the group ("Demo Group") instead setting it to the default group of the users doing the creation.



Related documentation

The following documentation discusses related topics: