Samba operates on top of the UNIX file system. This means it is subject to UNIX file system conventions and permissions. It also means that if the MS Windows networking environment requires file system behavior, that differs from UNIX file system behavior then somehow Samba is responsible for emulating that in a transparent and consistent manner.

It is good news that Samba does this to a large extent, and on top of that, provides a high degree of optional configuration to override the default behavior. We look at some of these overrides, but for the greater part we stay within the bounds of default behavior. Those wishing to explore the depths of control ability should review the smb.conf man page.

The following compares file system features for UNIX with those of MS Windows NT/200x:

There are many other subtle differences that may cause the MS Windows administrator some temporary discomfort in the process of becoming familiar with UNIX/Linux. These are best left for a text that is dedicated to the purpose of UNIX/Linux training and education.

There are three basic operations for managing directories: create, delete, rename. Managing Directories with UNIX and Windows compares the commands in Windows and UNIX that implement these operations.

The network administrator is strongly advised to read basic UNIX training manuals and reference materials regarding file and directory permissions maintenance. Much can be achieved with the basic UNIX permissions without having to resort to more complex facilities like POSIX ACLs or extended attributes (EAs).

UNIX/Linux file and directory access permissions involves setting three primary sets of data and one control set. A UNIX file listing looks as follows:

$ ls -la
total 632
drwxr-xr-x   13 maryo   gnomes      816 2003-05-12 22:56 .
drwxrwxr-x   37 maryo   gnomes     3800 2003-05-12 22:29 ..
dr-xr-xr-x    2 maryo   gnomes       48 2003-05-12 22:29 muchado02
drwxrwxrwx    2 maryo   gnomes       48 2003-05-12 22:29 muchado03
drw-rw-rw-    2 maryo   gnomes       48 2003-05-12 22:29 muchado04
d-w--w--w-    2 maryo   gnomes       48 2003-05-12 22:29 muchado05
dr--r--r--    2 maryo   gnomes       48 2003-05-12 22:29 muchado06
drwsrwsrwx    2 maryo   gnomes       48 2003-05-12 22:29 muchado08
----------    1 maryo   gnomes     1242 2003-05-12 22:31 mydata00.lst
--w--w--w-    1 maryo   gnomes     7754 2003-05-12 22:33 mydata02.lst
-r--r--r--    1 maryo   gnomes    21017 2003-05-12 22:32 mydata04.lst
-rw-rw-rw-    1 maryo   gnomes    41105 2003-05-12 22:32 mydata06.lst
$ 

The columns represent (from left to right) permissions, number of hard links to file, owner, group, size (bytes), access date, time of last modification, and file name.

An overview of the permissions field is shown in Overview of UNIX permissions field.

Figure 16.1. Overview of UNIX permissions field.

Any bit flag may be unset. An unset bit flag is the equivalent of "cannot" and is represented as a “-” character (see “Example File”)

-rwxr-x---   Means: 
 ^^^                The owner (user) can read, write, execute
    ^^^             the group can read and execute
       ^^^          everyone else cannot do anything with it.

Additional possibilities in the [type] field are c = character device, b = block device, p = pipe device, s = UNIX Domain Socket.

The letters rwxXst set permissions for the user, group, and others as read (r), write (w), execute (or access for directories) (x), execute only if the file is a directory or already has execute permission for some user (X), set user (SUID) or group ID (SGID) on execution (s), sticky (t).

When the sticky bit is set on a directory, files in that directory may be unlinked (deleted) or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable.

When the set user or group ID bit (s) is set on a directory, then all files created within it will be owned by the user and/or group whose `set user or group' bit is set. This can be helpful in setting up directories for which it is desired that all users who are in a group should be able to write to and read from a file, particularly when it is undesirable for that file to be exclusively owned by a user whose primary group is not the group that all such users belong to.

When a directory is set d-wx--x---, the owner can read and create (write) files in it, but because the (r) read flags are not set, files cannot be listed (seen) in the directory by anyone. The group can read files in the directory but cannot create new files. If files in the directory are set to be readable and writable for the group, then group members will be able to write to (or delete) them.

A file with the i attribute cannot be modified: it cannot be deleted
or renamed, no link can be created to this file and no data can be
written to the file. Only the superuser or a process possessing the
CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

User- and group-based controls can prove quite useful. In some situations it is distinctly desirable to force all file system operations as if a single user were doing so. The use of the force user and force group behavior will achieve this. In other situations it may be necessary to use a paranoia level of control to ensure that only particular authorized persons will be able to access a share or its contents. Here the use of the valid users or the invalid users parameter may be useful.

As always, it is highly advisable to use the easiest to maintain and the least ambiguous method for controlling access. Remember, when you leave the scene, someone else will need to provide assistance, and if he or she finds too great a mess or does not understand what you have done, there is risk of Samba being removed and an alternative solution being adopted.

User and Group Based Controls enumerates these controls.

Directory permission-based controls, if misused, can result in considerable difficulty in diagnosing the causes of misconfiguration. Use them sparingly and carefully. By gradually introducing each, one at a time, undesirable side effects may be detected. In the event of a problem, always comment all of them out and then gradually reintroduce them in a controlled way.

Refer to File and Directory Permission Based Controls for information regarding the parameters that may be used to set file and directory permission-based access controls.

The parameter documented in Other Controls are often used by administrators in ways that create inadvertent barriers to file access. Such are the consequences of not understanding the full implications of smb.conf file settings.

The best tool for share permissions management is platform-dependent. Choose the best tool for your environment.

Windows NT clients can use their native security settings dialog box to view and modify the underlying UNIX permissions.

This ability is careful not to compromise the security of the UNIX host on which Samba is running and still obeys all the file permission rules that a Samba administrator can set.

Samba does not attempt to go beyond POSIX ACLs, so the various finer-grained access control options provided in Windows are actually ignored.

From an NT4/2000/XP client, right-click on any file or directory in a Samba-mounted drive letter or UNC path. When the menu pops up, click on the Properties entry at the bottom of the menu. This brings up the file Properties dialog box. Click on the Security tab and you will see three buttons: Permissions, Auditing, and Ownership. The Auditing button will cause either an error message "A requested privilege is not held by the client" to appear if the user is not the NT administrator, or a dialog intended to allow an administrator to add auditing requirements to a file if the user is logged on as the NT administrator. This dialog is nonfunctional with a Samba share at this time, because the only useful button, the Add button, will not currently allow a list of users to be seen.

Clicking on the Ownership button brings up a dialog box telling you who owns the given file. The owner name will be displayed like this:

		SERVER\user (Long name)
		

SERVER is the NetBIOS name of the Samba server, user is the username of the UNIX user who owns the file, and (Long name) is the descriptive string identifying the user (normally found in the GECOS field of the UNIX password database). Click on the Close button to remove this dialog.

If the parameter nt acl support is set to false, the file owner will be shown as the NT user Everyone.

The Take Ownership button will not allow you to change the ownership of this file to yourself (clicking it will display a dialog box complaining that the user as whom you are currently logged onto the NT client cannot be found). The reason for this is that changing the ownership of a file is a privileged operation in UNIX, available only to the root user. Because clicking on this button causes NT to attempt to change the ownership of a file to the current user logged into the NT client, this will not work with Samba at this time.

There is an NT chown command that will work with Samba and allow a user with administrator privilege connected to a Samba server as root to change the ownership of files on both a local NTFS file system or remote mounted NTFS or Samba drive. This is available as part of the Seclib NT security library written by Jeremy Allison of the Samba Team and is downloadable from the main Samba FTP site.

The third button is the Permissions button. Clicking on it brings up a dialog box that shows both the permissions and the UNIX owner of the file or directory. The owner is displayed like this:

SERVER\ user (Long name)

SERVER is the NetBIOS name of the Samba server, user is the username of the UNIX user who owns the file, and (Long name) is the descriptive string identifying the user (normally found in the GECOS field of the UNIX password database).

If the parameter nt acl support is set to false, the file owner will be shown as the NT user Everyone, and the permissions will be shown as NT Full Control.

The permissions field is displayed differently for files and directories. Both are discussed next.

Modifying file and directory permissions is as simple as changing the displayed permissions in the dialog box and clicking on OK. However, there are limitations that a user needs to be aware of, and also interactions with the standard Samba permission masks and mapping of DOS attributes that also need to be taken into account.

If the parameter nt acl support is set to false, any attempt to set security permissions will fail with an "Access Denied" message.

The first thing to note is that the Add button will not return a list of users in Samba (it will give an error message saying "The remote procedure call failed and did not execute"). This means that you can only manipulate the current user/group/world permissions listed in the dialog box. This actually works quite well because these are the only permissions that UNIX actually has.

If a permission triplet (either user, group, or world) is removed from the list of permissions in the NT dialog box, then when the OK button is pressed, it will be applied as no permissions on the UNIX side. If you view the permissions again, the no permissions entry will appear as the NT O flag, as described above. This allows you to add permissions back to a file or directory once you have removed them from a triplet component.

Because UNIX supports only the “r”, “w”, and “x” bits of an NT ACL, if other NT security attributes such as Delete Access are selected, they will be ignored when applied on the Samba server.

When setting permissions on a directory, the second set of permissions (in the second set of parentheses) is by default applied to all files within that directory. If this is not what you want, you must uncheck the Replace permissions on existing files checkbox in the NT dialog before clicking on OK.

If you wish to remove all permissions from a user/group/world component, you may either highlight the component and click on the Remove button or set the component to only have the special Take Ownership permission (displayed as O) highlighted.

There are four parameters that control interaction with the standard Samba create mask parameters:

When a user clicks on OK to apply the permissions, Samba maps the given permissions into a user/group/world r/w/x triplet set, and then checks the changed permissions for a file against the bits set in the security mask parameter. Any bits that were changed that are not set to 1 in this parameter are left alone in the file permissions.

Essentially, zero bits in the security mask may be treated as a set of bits the user is not allowed to change, and one bits are those the user is allowed to change.

If not explicitly set, this parameter defaults to the same value as the create mask parameter. To allow a user to modify all the user/group/world permissions on a file, set this parameter to 0777.

Next Samba checks the changed permissions for a file against the bits set in the force security mode parameter. Any bits that were changed that correspond to bits set to 1 in this parameter are forced to be set.

Essentially, bits set in the force security mode parameter may be treated as a set of bits that, when modifying security on a file, the user has always set to be on.

If not explicitly set, this parameter defaults to the same value as the force create mode parameter. To allow a user to modify all the user/group/world permissions on a file with no restrictions, set this parameter to 000. The security mask and force security mode parameters are applied to the change request in that order.

For a directory, Samba performs the same operations as described above for a file except it uses the parameter directory security mask instead of security mask, and force directory security mode parameter instead of force security mode .

The directory security mask parameter by default is set to the same value as the directory mask parameter and the force directory security mode parameter by default is set to the same value as the force directory mode parameter. In this way Samba enforces the permission restrictions that an administrator can set on a Samba share, while still allowing users to modify the permission bits within that restriction.

If you want to set up a share that allows users full control in modifying the permission bits on their files and directories and does not force any particular bits to be set on, then set the following parameters in the smb.conf file in that share-specific section:

If a file has no UNIX read access for the owner, it will show up as “read-only” in the standard file attributes tabbed dialog. Unfortunately, this dialog is the same one that contains the security information in another tab.

What this can mean is that if the owner changes the permissions to allow himself or herself read access using the security dialog, clicks on OK to get back to the standard attributes tab dialog, and clicks on OK on that dialog, then NT will set the file permissions back to read-only (as that is what the attributes still say in the dialog). This means that after setting permissions and clicking on OK to get back to the attributes dialog, you should always press Cancel rather than OK to ensure that your changes are not overridden.

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.

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

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

The following complaint has frequently been voiced on the Samba mailing list: “ We are facing some troubles with file/directory permissions. I can log on the domain as admin user (root), and there's a public share on which everyone needs to have permission to create/modify files, but only root can change the file, no one else can. We need to constantly go to the server to chgrp -R users * and chown -R nobody * to allow other users to change the file. ”

Here is one way the problem can be solved:

When you have a user in admin users, Samba will always do file operations for this user as root, even if force user has been set.

Question: “When user B saves a word document that is owned by user A, the updated file is now owned by user B. Why is Samba doing this? How do I fix this?”

Answer: Word does the following when you modify/change a Word document: MS Word creates a new document with a temporary name. Word then closes the old document and deletes it, then renames the new document to the original document name. There is no mechanism by which Samba can in any way know that the new document really should be owned by the owners of the original file. Samba has no way of knowing that the file will be renamed by MS Word. As far as Samba is able to tell, the file that gets created is a new file, not one that the application (Word) is updating.

There is a workaround to solve the permissions problem. It involves understanding how you can manage file system behavior from within the smb.conf file, as well as understanding how UNIX file systems work. Set on the directory in which you are changing Word documents: chmod g+s `directory_name'. This ensures that all files will be created with the group that owns the directory. In smb.conf share declaration section set:

These two settings will ensure that all directories and files that get created in the share will be readable/writable by the owner and group set on the directory itself.