Unofficial Samba + ACL Howto

18 July 2003, version 0.2 (preliminary)

Maintained by Paul Eggleton (

1. Introduction

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.

1.1 Contributing

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

1.2 About the author

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 ( instead. Make sure you have read the docs and searched the web a bit before posting.

1.3 Distribution

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.

2. Setting up

2.1. Install ACL kernel patches

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 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, 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).

2.2. Update core utilities & libs

Instructions on show what you need to do here. Use the RPMs if running Red Hat.

2.3. Enable ACL support for the file system

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

2.4. Install Samba with ACL support

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.

Source RPM

  1. Run rpm -i samba-x.x.x.src.rpm.
  2. Add --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).
  3. Run rpmbuild --bb specfile.spec to build the binary RPM.
  4. Go into /usr/src/redhat/RPMS/i386 and install the RPM as normal.

Source tarball

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 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.

2.5. Set up Samba

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.

2.5.1 Instructions for Samba 2.2.x

Set the following options in /etc/samba/smb.conf:

To join the domain, use:


2.5.2 Instructions for Samba 3.0 beta

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:

To join the domain, use net ads join -U Administrator.

2.5.3 Winbind, PAM etc.

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

2.5.4 Services

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

2.5.5 Testing

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.

    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.

3. FAQ

3.1 General

3.1.1. Permissions aren't quite working the way I expect. What's going on?

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.).

3.1.2. I'm logged in as Administrator - why can't I edit permissions or change ownership of a file on a domain-connected Samba share?

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

3.1.3. How do I back up files with ACLs?

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 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.

3.1.4. Why can't I use the "Authenticated Users" or "Administrators" groups on a Samba share?

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.