3

I have an Ubuntu 10.04.4 LTS server running Samba, and joined to our Active Directory domain using PBIS (formerly likewise-open.) Samba is configured to do authentication using AD users/groups, and this is working correctly. Also, standard Linux permissions (user, group, others) world properly with Samba. BUT, Samba seems to totally ignore any permissions set with extended ACLs.

I have tried various smb.conf configurations I have seen recommended elsewhere, and none of them seem to have any effect.

Machine Setup:

  • Files share is on it's own drive. Mount info from /etc/fstab for the drive is:
    • UUID=372aa637-4b7b-45cc-8340-9d028893c196 /media/news-drive ext4 user_xattr,acl 0 2
  • Machine is joined to domain using PBIS (formerly likewise-open)
  • Samba config for the share is:
[shared]
   comment = , 
   nt acl support = yes
   admin users = 
   force user = 
   force group = \domain^users
   create mask = 0770
   directory mask = 0770
  • Global Samba Config
workgroup = 
dns proxy = no
server string = 
load printers = no
cups options = raw
guest account = pcguest
log file = /var/log/samba/%m.log
max log size = 50
security = ADS
realm = 
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
interfaces = 172.16.0.20 10.4.1.20 127.0.0.1
bind interfaces only = yes
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
map to guest = Bad User
  • I have also used some of these in the global config, without success
idmap backend = idmap_rid:=16777216-33554431
nt acl support = yes
inherit acls = Yes
map acl inherit = Yes
map archive = no
map hidden = no
map read only = no
map system = no
store dos attributes = yes
inherit permissions = Yes
template shell = /bin/false
winbind use default domain = no

What am I missing here, to get Samba to work with the extended ACLs?

An Example of What is Happening

I have a folder in a samba share. The share itself is wide open within our domain (the "valid users" setting is set to the "Domain Users" group for the AD domain.) Within that share, I have a folder with more restrictive permissions at the file system level (owned by one AD user, with the group set to an AD group with just a few people in it and permissions chmod-ed to 770)

The issue is, I need to give access to that folder to another AD group, so I run "setfacl -m u::rwx " to give them permission to access it. This works within Linux (if I ssh in which one of those users and navigate to the folder)...but if I connect to the SMB share with that same user, and try and navigate to that folder, access is denied.

woodsbw
  • 569
  • 2
  • 7
  • 18
  • hmmm....I really don't see a specific question here. – mdpc Dec 19 '12 at 21:45
  • Sorry, I thought the "what am I doing wrong" was implied. :) – woodsbw Dec 19 '12 at 22:05
  • I guess I still don't understand the specific problem. A specific example might help everybody to understand your problem. Do you want Samba to map NTFS permission to the underlying Linux ACLs assigned for the windows user to see/use? – mdpc Dec 19 '12 at 22:06
  • Added to question – woodsbw Dec 19 '12 at 22:15

2 Answers2

5

Coming late to this question, I'd still like to point to the official Samba documentation for support of ACLs. This is valid for Samba 4.0.0 onwards, which certainly was not available at the time this question got asked. But since the question pops up in search engines, this link might be helpful.

The basic steps are:

1. Ensure the file system supports acls (ext4 nowadays does by default, no need for extra mount options)

2. Ensure Samba was compiled with ACL support. (Yes, by default on Ubuntu 14.04 LTS):

smbd -b | grep HAVE_LIBACL

3. Enable ACL by setting the following in the [global] section of /etc/samba/smb.conf:

vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

For details really visit the official docs as linked to above.

cfi
  • 248
  • 5
  • 14
2

That's because force user, force group, create mask and directory mask enforce use of tradidional unix style permissions which can't be combined with inheriting ACLs. Your default ACLs must reside on filesystem-level of the folder not on the samba share itself for inheritance to work but be aware that contradictory permissions will always deny access eg. when a user has permission as user but not as group samba will disallow access when using ACLs (which seems to me like a bug) eg: the user nobody is member of nogroup then ACLs needs to allow nobody & nogroup write permission otherwise write access is denied. Only samba behaves this way!

A possible way to create a folder with inheriting default permissions could be:

me@myHost:/shares$ getfacl myShare/
# file: myShare/
# owner: JohnDoe
# group: domain\040users
user::rwx
group::rwx          #effective:r-x
group:domain\040users:rwx   #effective:r-x
group:domain\040admins:rwx  #effective:r-x
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:domain\040users:rwx
default:group:domain\040admins:rwx
default:mask::rwx
default:other::r-x

The section with the default:* values is the interesting part for inheritance because any new file or folder will get these when created inside the myShare folder. See setfacls man page for details of setting default: values on a file or folder. Now the problem with using create mask or directory mask on a folder with default:ACLs set is that samba will then override these default values and in most cases these mask statements are only useful as long as you want the whole folder and it's files containing only a single owner and group. ACLs are harder to configure but offer much more flexibility as usual on windows machines. For samba to honor these default:*:: permissions inherit acls needs to be set in [global] section:

[global]
    ; Important if ACLs (eg: setfacl) contain default entries
    ; which samba honors only if this is set to 'yes'.
    inherit acls = yes

[...]

[myShare]
    comment = Put your files here
    path = /shares/myShare
    writeable = yes

This would allow a share where everyone can write to the share ... but (!) that doesn't mean necessarily that it's allowed on filesystem-level because the myShare folder just allows domain users. Anyway for the paranoid the share permissions can be narrowed by allowing only specific groups:

    write list = @"domain users"

which implicates writeable=yes but only for groups defined in write list. Ensure that permissions on share and on folder are free of contradictions eg:

    write list = @"other group"

would allow other group to write to the share but since myShare folders allows only domain users to write it would fail obviously.

3ronco
  • 143
  • 7