Skip to content
FreeBSDDeep Dive Published Updated 5 min readViews unavailable

FreeBSD ACL Operations: Identify POSIX.1e and NFSv4 Semantics

Identify the ACL model on FreeBSD, interpret POSIX masks and NFSv4 entries, and validate inheritance before changing access on UFS or ZFS.

An ACL is not just a longer version of a mode such as 644. FreeBSD supports both POSIX.1e ACLs and NFSv4 ACLs, and their entry grammars, inheritance models, and evaluation rules differ. The same getfacl and setfacl command names cover both models, but some flags only apply to one. Start by identifying the mounted filesystem and ACL type before interpreting output or copying a command from another host.

This guide uses FreeBSD 15.1 documentation for the examples. Check the manuals installed on the target release, especially when a filesystem is shared with another operating system or an SMB server.

Identify the filesystem and active ACL model

Begin with read-only inventory. Record the OS release, current mounts, and the ZFS ACL type when the path is on ZFS:

freebsd-version -kru
mount
zfs get -o name,property,value,source acltype,aclmode,aclinherit tank/team
getfacl -v /srv/team /srv/team/report.txt

Run zfs get only for a ZFS dataset. On UFS, inspect the active mount options: FreeBSD 15.1 mount(8) distinguishes acls, which enables POSIX.1e ACLs, from nfsv4acls, which enables NFSv4 ACLs. Those UFS mount flags are mutually exclusive. A configuration file that says one thing is not proof that the filesystem is currently mounted with that option.

For OpenZFS on FreeBSD, acltype is the relevant dataset property. The FreeBSD 15.1 zfsprops(7) manual describes nfsv4 as the FreeBSD default. Its posix ACL type is specific to Linux and is not functional on other platforms. Do not infer that a ZFS dataset has POSIX ACL behavior merely because another operating system can use that value.

The ACL listing itself is a second check. POSIX output commonly has entries such as user::rw- and group::r--. NFSv4 output uses tags such as owner@, group@, and everyone@, plus a permission set, inheritance flags, and an allow or deny type. With NFSv4 ACLs, getfacl -v displays the mask and flags in verbose form; for POSIX ACLs, that option is ignored.

Read a POSIX ACL as a bounded group class

A POSIX.1e ACL adds named user and group entries to the owner, owning-group, and other entries. Once an extended entry exists, the ACL mask is a maximum for the group class: it limits named users, named groups, and the owning-group entry. It does not limit the file owner’s entry or other.

For example, this ACL gives a named user a stored read/write entry, while the mask caps effective group-class rights at read:

setfacl -m u:auditor:rw-,mask::r-- /mnt/posix-acl-lab/report.txt
getfacl /mnt/posix-acl-lab/report.txt

Use that syntax only on a disposable file on a filesystem mounted for POSIX ACLs. In the output, do not read user:auditor:rw- as the user’s effective access without also reading mask::r--. The mask is also reflected in the group permission bits shown by tools such as ls and stat; those mode bits no longer summarize every individual ACL entry.

POSIX directory inheritance uses a default ACL. FreeBSD’s setfacl -d applies to default entries on directories, and the mandatory owner, group, other, and mask entries must be present. New objects inherit default ACL entries, but the permissions requested by the creating application still matter. A default ACL is not a guarantee that every new file will be executable or writable by every inherited principal.

Read NFSv4 entries in their visible order

An NFSv4 ACL uses richer rights such as read_data, write_data, append_data, delete_child, and write_acl. Entries can also carry inheritance flags such as file-inherit and directory-inherit. Unlike POSIX default ACLs, NFSv4 inheritance is expressed on ACEs; FreeBSD’s manual says inheritance flags other than the inherited marker may be set only on directories.

NFSv4 ACEs are evaluated in their visible order. A matching deny earlier in the list can change the result of a later allow, so sorting or rewriting entries for visual neatness is not a safe repair. Also, everyone@ is not the POSIX other class: FreeBSD defines it to include the file owner and owning group too.

A syntax illustration for a named-user read allow entry is:

setfacl -m u:auditor:r::allow /mnt/nfsv4-acl-lab/report.txt
getfacl -v /mnt/nfsv4-acl-lab/report.txt

Apply it only to a disposable file on an NFSv4 ACL filesystem. Confirm the final ACE order, inheritance flags, and permission letters. Do not translate a POSIX rwx string mechanically into NFSv4 rights: the latter can distinguish operations that traditional mode bits combine.

Make changes on a matching test filesystem

A safe ACL test must use the same filesystem type and ACL model as the target, because a UFS mount flag or ZFS property determines which grammar the filesystem accepts. Keep separate POSIX and NFSv4 fixtures; one UFS mount cannot use both mutually exclusive ACL flags at the same time.

Before a production change, capture getfacl output for the file and its parent directories, record ownership and mode, and confirm which user and groups the application actually uses. Prefer a least-privilege change on a disposable fixture, then test access as the intended account. An ACL dump alone does not prove the process can reach the file: directory search permission, mount state, MAC policy, and application identity still participate in access.

Be equally specific when removing entries. FreeBSD documents setfacl -bn for removing extended POSIX access entries while preserving the three mandatory entries, and setfacl -b for removing NFSv4 ACL entries. The -d, -k, and -n options are not applicable to NFSv4 ACLs. A recursive command can affect a large tree; do not add -R until the exact path, symlink behavior, inheritance plan, and backup are reviewed.

ACL compatibility is a migration concern. Before copying data between FreeBSD, Linux, Windows, or a NAS, test whether the destination can represent the source’s ACE ordering, deny entries, rights, and inheritance. A successful file copy or matching ls -l mode does not establish equivalent authorization. Validate both the stored ACL and the access behavior of the actual service.

Related:

Sources:

Comments