Permissions

Windows supports a variety of permissions that can be assigned in a granular way for shares and the folders and files they contain (Figure 2), whereas Linux only supports Read, Write, and Execute permissions for the owner, group, and "rest of the world" roles. From the perspective of a Windows admin, that is not proper rights management.

Figure 2: Windows uses a complex, finely granular authorization concept.

Connecting these two worlds therefore is not simple, but it's necessary. If Samba is not the only way to access the data (e.g., local logins or an NFS share on the server), you must make sure that the access rights you set cannot be worked around locally. In other words, it is not enough simply to save the permissions in a database; you also need to include the Linux filesystem.

Early versions of Samba converted the Windows permissions to Linux flags and ignored other access control settings. This solution is obviously unsatisfactory, so the next step is to support POSIX ACLs. This means that there is at least the possibility to assign permissions specifically to individual users (even if they are not the owner) and individual groups (Listing 6).

This approach is a step forward, but unfortunately it is not yet sufficient: Windows supports not only read, write, execute, but also unusual permissions such as "delete subfolders and files, but not the folder itself."

These permissions cannot currently be mapped on the filesystem in Linux. Nevertheless, it is important to keep and implement them in the Windows world at least. To do this, Samba uses advanced file attributes, which allow arbitrary variables to be associated with a file in certain namespaces (Listing 7).

Extended attributes therefore offer the possibility of storing arbitrary metadata for a file. Samba (or more precisely, the vfs_acl_xattr module) now leverages these capabilities to save permissions that cannot otherwise be mapped:

$ getfattr -n security.NTACL /tank/herbert/
# file: tank/herbert/
security.NTACL=0sAwADAAAAAgAEAAI...

A minor issue exists here, however: Not all filesystems support these mechanisms; in particular, ZFS on Linux does not support them. On Solaris and FreeBSD, the vfs_zfsacl module provides a remedy, but it does not exist on Linux.

You can work around this with the vfs_acl_tdb module, which stores the permissions in a database file. This module also provides an option for modifying the POSIX ACLs; thus, given a careful configuration, no problems are to be expected in the event of third-party access. However, this solution does not scale as well as the use of extended attributes, because database access can quickly become a bottleneck. Furthermore, snapshots, high availability, and failover are not so easy to implement. If you need features such as those offered by ZFS, you should consider using Btrfs.

Feature Matrix

The selection of the filesystem on the storage server has an additional effect on the functions that a file server can offer its users, beyond support for ACLs. Which of these factors is relevant in practice, of course, always depends on the corporation and the type of data stored. Other interesting functions include:

• Quotas: The filesystem lets you set size limits for directories for individual users and groups.
• Filesystem shrink: The filesystem can shrink as well as grow. If you miscalculated when setting up storage, this provides an easy fix without having to move the data.
• Compression: The filesystem supports compression of data before it's stored and can thus use the available space more effectively.
• Deduplication: The filesystem detects duplicate data blocks and stores them once only, and so use the available space more efficiently.
• Snapshots: The filesystem supports the ability to create subvolumes and snapshots. In this way, the entire directory tree or subtree can be frozen in a matter of seconds so that its state no longer changes.
• Redundancy: The filesystem itself offers the possibility of redundant data storage so that the failure of a hard disk can be compensated for in a way that is invisible to the user. There is no need to resort to RAID.
• Distributed: Distributed and cluster filesystems like OCFS2 or Ceph offer different ways to look at storage on multiple hosts as a single large storage area. Data is stored redundantly and distributed on these hosts to compensate for the failure of individual hosts in a way that is transparent to the user.

An overview of the back-end filesystems used for Samba in these contexts is provided in Table 1. Giving a general recommendation for or against an individual filesystem does not make sense, because it is driven by the intended use and the expected growth of data.