Maintained by Paul Eggleton (bluelightning@bluelightning.org)
Access Control Lists (ACLs) provide a much more flexible way of specifying permissions on a file or other object than the standard Unix user/group/owner system. Windows NT and above, when running on an NTFS partition, use ACLs to specify permissions on files and directories. This document attempts to show how you can enable ACL support on your Linux box and use Samba to provide an SMB file server for use by machines in a Windows 2000 domain.
ACLs are best stored in the actual file system itself. To that end, there are patches available for ext2 and ext3 that enable ACL support using Extended Attributes (EAs). SGI's XFS also has ACL support built in, but XFS is not currently covered in this document.
In the near future, this howto will not be as important, as moves are underway to include this support by default in many distributions (Mandrake reportedly has done it already; Red Hat almost did in version 9 but there were problems interacting with NFS and it was removed at the last minute).
At this time, this document is not 100% complete. I have assumed you are joining to a Windows 2000 domain which is using Active Directory, you aren't trying to use Samba as a domain controller, and that you're using ext2 or ext3 on Linux.
Please feel free to send me additions/corrections/enhancements to this document, and I will do my best to integrate them. You can reach me at bluelightning@bluelightning.org.
I'm Paul Eggleton, a software developer and part-time server admin at CJN Technologies Ltd, based in Auckland, New Zealand. Most of what is in this document was picked up as a result of trying to set up a Windows user profile store machine here at our office, using Samba on Red Hat Linux.
This is not an official document. I am not affiliated with the Samba project in any way. If you have concerns relating to this howto please contact me directly rather than the Samba project.
On the other hand, please do not email me tech support questions - most of what I know on this subject is in this document. Use the samba mailing list (samba@lists.samba.org) instead. Make sure you have read the docs and searched the web a bit before posting.
This document may be freely distributed in its entirety. Please do not distribute modified versions; contact me and I will make the changes if necessary.
The ACL code has not yet made it into the stable kernel, so you will need to patch the kernel to enable support. Patches are available at acl.bestbits.at. Note that many distributions use their own customised kernels which might not be compatible with the patches (if the patch applies without errors, everything's OK, otherwise grab the stock kernel sources from kernel.org, unpack, patch, and select options with care - see the kernel howto). You will need to be running a recent kernel (2.4.20 or 2.4.21, at the time of writing). Official support in the kernel is coming in 2.6.
ACLs on ext2/3 are implemented through extended attributes (EAs). You need to enable both the EA and ACL kernel options for ext2 and/or ext3 (depending on which file system you are using - you can enable both).
Instructions on acl.bestbits.at show what you need to do here. Use the RPMs if running Red Hat.
If you're using ext2/ext3 then you will need to add acl to the mount
options. You can do this in /etc/fstab, but you have to be careful - some
distributions will overwrite this at will (Red Hat 8 has done this to me). If
you go the fstab route you also have to be careful that you have actually got
ACL support working in the kernel at this point, or you will have major problems
starting up (the kernel won't recognise the acl option, the mount read-write
will fail and Linux won't boot properly). Another solution (which I used) was to
add the acl flag later, in /etc/rc.d/rc.local - use the following command:
mount / -o remount,acl
You will likely need to recompile Samba with ACL support, as it is off by default. You will first need to choose whether you want to install the latest stable build (2.2.x) or development build (3.0 beta). 3.0 is recommended at this time for better ACL support (and better all-round operation). If you value stability over functionality you may want to stick with 2.2.x, but if you are interested in having Samba improved you would do well to install 3.0 and report any problems you find to the Samba team.
Personally, running under Red Hat 9 I built Samba from the source RPM. You can build from the source tarball instead if you know what you're doing (on non-RPM systems you will have to do this). I find it easier to use the source RPM, and this is definitely the cleanest way to do it on a Red Hat installation.
rpm -i samba-x.x.x.src.rpm.--with-acl-support ACL support option to the Samba spec file in
/usr/src/redhat/SPECS (at the end of the CFLAGS= setting, which is
split onto multiple lines using \ characters - so you'll need to make sure you continue this).rpmbuild --bb specfile.spec to build the binary RPM./usr/src/redhat/RPMS/i386 and install the RPM as normal.
Run ./configure --help to get a list of options. You probably know what options
you want to select - just remember to use --with-acl-support as well.
You will need to remember to copy the
libnss_winbind.so file from source/nsswitch to /lib, and then run
ldconfig. This will allow you to use the "winbind" option in /etc/nsswitch.conf
to enable mapping between Windows users and groups and Unix users and groups.
This is covered in great detail elsewhere (if all else fails, read the manual
- man smb.conf). You can try using SWAT instead. I have never used
it myself.
Set the following options in /etc/samba/smb.conf:
workgroup = DOMAINNAME
security = domain
password server = DOMAINCONTROLLER
encrypt passwords = yes (very important - read
encryption.txt in the Samba docs for more info)
winbind uid = 10000-65000 and winbind gid =
10000-65000 (uncomment existing lines)
winbind enum users = yes
winbind enum groups = yes To join the domain, use:
smbpasswd -j DOMAINNAME -r DOMAINCONTROLLER -U DOMAINNAME\\Administrator
You will need to use slightly different settings if you are using Samba 3.0 beta:
Set the following options in /etc/samba/smb.conf:
realm = DOMAINNAME as well as workgroup =
DOMAINNAME
encrypt passwords = yes (very important - read
encryption.txt in the Samba docs for more info)
password server = DOMAINCONTROLLER
security = ADS
idmap uid = 10000-65000 and idmap gid =
10000-65000 (uncomment existing lines)
winbind enum users = yes
winbind enum groups = yes To join the domain, use net ads join -U Administrator.
Winbind is the part of Samba which provides name<=>ID translation for users and groups. Once this is working, you will be able to use names from the domain on your Linux box as if they were real Unix users, without having to add them to /etc/passwd.
To set up winbind, see winbind.txt (part of the Samba documentation) or this document.
You don't need to set up PAM with winbind support unless you actually need to be able to log into the Linux machine directly with credentials from the Windows domain, or you want to provide domain authentication to other services (eg. ftp).
You may also need to set the user for Winbind to use to connect to the server with. Do this by running the following command:
wbinfo --set-auth-user DOMAINNAME\\Administrator%password
Having configured Samba you will need to make sure it is running and will be
started upon boot. If you built from source on a Red Hat system you will want to
copy the smb.init and winbind.init files from packaging/RedHat to
/etc/init.d/ and do the following:
service smb start service winbind start chkconfig --level 345 smb on chkconfig --level 345 winbind on
To make sure everything is working, use wbinfo -u to list all
users on the domain, and wbinfo -g for the groups. If you get lists
of users and groups then it's working. You can use getent group
and getent passwd to make sure domain users and groups are actually
being mapped to Unix users and groups. As a final test you may want to make
sure you can change owner and group of a file to a user and group on the domain.
Now your server is set up and joined to the domain, you can add some shares.
[testshare]
comment = Test share
path = /usr/local/smbshare
public = yes
writable = yes
create mask = 0700
directory mask = 0700
directory security mask = 0700
admin users = DOMAINNAME\Administrator
A share configuration similar to the above works well as a user home directories share.
Having added a share you should be able to connect to it from a Windows machine and verify that permissions editing is working. Note that when editing permissions you have to keep in mind that even with ACL support switched on, Samba still translates Unix user/group/other into ACL entries under Windows (Owner of file, Owner's group, Everyone), because that's how POSIX ACLs work. This can create some serious confusion if you expect it to work exactly like a Windows 2000 server, but at this time there is no other alternative.
When editing permissions on an ACL-enabled share under Windows, it's important to remember that the standard Unix permissions are also reflected in the ACLs. So if the owner of a file is Bob, the group of the file under Unix is DOMAIN\MyGroup and the Unix permissions are rwxrw-r-- then the Windows permissions you should see are as follows:
| User/Group | Permission |
| Bob | Full Control |
| MyGroup | Read/Write |
| Everyone | Read |
I haven't yet completely figured it out, but Samba doesn't seem to translate actions in the Windows permissions editor to changes in the Unix permissions perfectly all of the time, so sometimes weird things happen (eg. removing Everyone from a file doesn't always work, CREATOR GROUP and CREATOR OWNER are added sometimes, etc.).
Under Linux and probably most Unixes, you can't change permissions on a file unless you are the current owner of the file or root, and you can't change ownership of a file unless you are root. So you will need to make yourself operate as root when you are logged in as Administrator. To do this, add the following line to the section in smb.conf for the share you are trying to administer:
admin users = DOMAINNAME\Administrator
Currently, if you are using the winbind use default domain option
then you will need to omit the domain name:
admin users = Administrator
If you use cp to make copies of files with attached ACLs, you
need to use the -p switch. mv always preserves ACLs if possible.
Of course, preservation of the ACLs when using cp or mv
is not possible if the destination does not support ACLs itself.
The standard GNU tar does not support ACLs at this time, but you can use the Star archiver instead which does. ACL-enabled Star is available from acl.bestbits.at. There are some command line options you need to use for the ACLs to be enabled - read the man page.
Alternatively, you can back up the ACLs separately using the getfacl
command and use setfacl to restore them.
These are part of the "Builtin" groups under Windows 2000. Presumably there is some sort of translation going on in the normal case (between two Windows machines). With Samba they do not seem to work. However, you can use the "Domain Admins" group instead of Administrators.