Setting up a Share Using POSIX ACLs: Difference between revisions

From SambaWiki
(Major rewrite with more details/examples.)
m (grammar)
Line 1: Line 1:
= Introduction =
= 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|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.
On every Samba host you can, as on any MS Windows OS, share a folder to make it accessible for other users. There's no difference if this host is a 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.


'''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 note:''' Samba Active Directory Domain Controllers have extended ACL support enabled globally, to enable [[Shares_with_Windows_ACLs|management of share permissions and ACLs via Windows]]!




Line 11: Line 11:
= Execute bit on files =
= 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):
Prior to Samba 4.0, the execution bit of files was not checked. This means 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, as 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
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.
We only recommend this as a workaround, until you can fix the permissions by adding the x-bit to files on a share that should be executable.




Line 42: Line 42:
= Setup share permissions (optional) =
= 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.
As 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 are made.




Line 54: Line 54:
invalid users = +SAMDOM\"Demo Group" SAMDOM\foobar
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!
The example above allows connection 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!




Line 87: Line 87:
# chown foobar:"Demo Group" /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.
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 means 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.





Revision as of 19:34, 31 October 2015

Introduction

On every Samba host you can, as on any MS Windows OS, share a folder to make it accessible for other users. There's no difference if this host is a 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, to enable management of share permissions and ACLs via Windows!



Execute bit on files

Prior to Samba 4.0, the execution bit of files was not checked. This means 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, as 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

We only recommend this as a workaround, until you can fix the permissions by adding the x-bit to files on a share that should be executable.



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)

As 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 are made.


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 example above allows connection 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 means 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: