Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Samba HowTo Guide
Prev Home Next

Windows NT/200X ACLs and POSIX ACLs Limitations

Windows administrators are familiar with simple ACL controls, and they typically consider that UNIX user/group/other (ugo) permissions are inadequate and not sufficiently fine-grained.

Competing SMB implementations differ in how they handle Windows ACLs. Samba handles Windows ACLs from the perspective of UNIX file system administration and thus adopts the limitations of POSIX ACLs. Therefore, where POSIX ACLs lack a capability of the Windows NT/200X ACLs, the POSIX semantics and limitations are imposed on the Windows administrator.

POSIX ACLs present an interesting challenge to the UNIX administrator and therefore force a compromise to be applied to Windows ACLs administration. POSIX ACLs are not covered by an official standard; rather, the latest standard is a draft standard 1003.1e revision 17. This is the POSIX document on which the Samba implementation has been implemented.

UNIX vendors differ in the manner in which POSIX ACLs are implemented. There are a number of Linux file systems that support ACLs. Samba has to provide a way to make transparent all the differences between the various implementations of POSIX ACLs. The pressure for ACLs support in Samba has noticeably increased the pressure to standardize ACLs support in the UNIX world.

Samba has to deal with the complicated matter of handling the challenge of the Windows ACL that implements inheritance , a concept not anticipated by POSIX ACLs as implemented in UNIX file systems. Samba provides support for masks that permit normal ugo and ACLs functionality to be overrided. This further complicates the way in which Windows ACLs must be implemented.


In examining POSIX ACLs we must consider the manner in which they operate for both files and directories. File ACLs have the following significance:

# file: testfile      <- the file name
# owner: jeremy       <-- the file owner
# group: users        <-- the POSIX group owner
user::rwx             <-- perms for the file owner (user)
user:tpot:r-x         <-- perms for the additional user `tpot'
group::r--            <-- perms for the file group owner (group)
group:engrs:r--       <-- perms for the additonal group `engineers'
mask:rwx              <-- the mask that is `ANDed' with groups
other::---            <-- perms applied to everyone else (other)

Directory ACLs have the following signficance:

# file: testdir       <-- the directory name
# owner: jeremy       <-- the directory owner
# group: jeremy       <-- the POSIX group owner
user::rwx             <-- directory perms for owner (user)
group::rwx            <-- directory perms for owning group (group)
mask::rwx             <-- the mask that is `ANDed' with group perms
other:r-x             <-- perms applied to everyone else (other)
default:user::rwx     <-- inherited owner perms
default:user:tpot:rwx <-- inherited extra perms for user `tpot'
default:group::r-x    <-- inherited group perms
default:mask:rwx      <-- inherited default mask
default:other:---     <-- inherited permissions for everyone (other)

Mapping of Windows File ACLs to UNIX POSIX ACLs

Microsoft Windows NT4/200X ACLs must of necessity be mapped to POSIX ACLs. The mappings for file permissions are shown in How Windows File ACLs Map to UNIX POSIX File ACLs. The # character means this flag is set only when the Windows administrator sets the Full Control flag on the file.

Table15.5.How Windows File ACLs Map to UNIX POSIX File ACLs

Windows ACE File Attribute Flag

Full Control


Traverse Folder/Execute File


List Folder/Read Data


Read Attributes


Read Extended Attribures


Create Files/Write Data


Create Folders/Append Data


Write Attributes


Write Extended Attributes


Delete Subfolders and Files




Read Permissions


Change Permissions


Take Ownership


As can be seen from the mapping table, there is no one-to-one mapping capability, and therefore Samba must make a logical mapping that will permit Windows to operate more-or-less the way that is intended by the administrator.

In general the mapping of UNIX POSIX user/group/other permissions will be mapped to Windows ACLs. This has precedence over the creation of POSIX ACLs. POSIX ACLs are necessary to establish access controls for users and groups other than the user and group that own the file or directory.

The UNIX administrator can set any directory permission from within the UNIX environment. The Windows administrator is more restricted in that it is not possible from within Windows Explorer to remove read permission for the file owner.

Mapping of Windows Directory ACLs to UNIX POSIX ACLs

Interesting things happen in the mapping of UNIX POSIX directory permissions and UNIX POSIX ACLs to Windows ACEs (Access Control Entries, the discrete components of an ACL) are mapped to Windows directory ACLs.

Directory permissions function in much the same way as shown for file permissions, but there are some notable exceptions and a few peculiarities that the astute administrator will want to take into account in the setting up of directory permissions.

Samba HowTo Guide
Prev Home Next

  Published under the terms fo the GNU General Public License Design by Interspire