Access Control

FlexFS provides multiple layers of access control that work together to protect data and enforce security policies.

POSIX permissions

FlexFS is a fully POSIX-compliant filesystem and enforces standard Unix file permissions (owner, group, other with read/write/execute bits). By default the kernel performs the checks, using the FUSE default_permissions option against the ownership and mode flexFS reports. On mounts where the client enforces instead — --rootSquash, or --acl on a kernel older than 4.9 — the checks run in the mount client against the calling process’s UID and GID. See Extended ACLs.

Root squashing

Root squashing maps uid=0 and gid=0 to a specified non-root user, preventing root users on mount clients from having root-level access to the filesystem.

Enabling root squashing

On the mount client:

mount.flexfs start my-volume /mnt/data --rootSquash

By default, root is mapped to uid=65534 / gid=65534 (the nobody user). You can customize the mapping:

mount.flexfs start my-volume /mnt/data \
  --rootSquash \
  --rootSquashUID 1000 \
  --rootSquashGID 1000

Root squashing can also be set as a volume-level flag via configure.flexfs, in which case it applies to all mounts of that volume.

Note

When root squashing is enabled, extended ACLs and xattr support are automatically enabled as well, since they are required for the squashing implementation.

Extended ACLs

FlexFS supports POSIX.1e extended access control lists (ACLs), which allow fine-grained per-user and per-group permissions beyond the standard owner/group/other model.

Enabling ACLs

On the mount client:

mount.flexfs start my-volume /mnt/data --acl

ACLs need kernel support that arrived in Linux 4.9. On any current distribution this is present and an --acl mount performs the same as a mount without it. On older systems — in practice RHEL/CentOS 7 — the mount client enforces ACLs itself instead: still correct, but slower, because the kernel cannot cache file metadata when the client is doing the checking. The same applies whenever --rootSquash is used, on any kernel.

The mount log records which is in effect:

ACL enforcement: kernel (default_permissions + FUSE_POSIX_ACL)
ACL enforcement: client (userspace POSIX.1e evaluation)

On the rare kernel that is new enough but was built without POSIX ACL support, an --acl mount refuses to start rather than run with ACLs partly ignored. See Troubleshooting.

Or as a volume-level flag via configure.flexfs.

The same principle applies to a mount where ACLs are simply not enabled: it does not run with ACLs partly ignored, it has no POSIX ACL support at all, like a filesystem whose kernel lacks it. setfacl and getfacl fail with Operation not supported, ACLs already stored on the volume by ACL-enabled mounts are neither reported nor applied, and access is governed by the owner/group/other mode bits alone. Because a shared volume’s access control is only as strong as its weakest mount, set the volume-level acl flag whenever ACLs are load-bearing — it makes every mount of the volume enforce them, regardless of each mount client’s local flags.

Once enabled, use standard Linux ACL tools:

# Set an ACL
setfacl -m u:alice:rwx /mnt/data/project

# View ACLs
getfacl /mnt/data/project

# Remove an ACL
setfacl -x u:alice /mnt/data/project

Extended attributes (xattrs)

Extended attributes are enabled with the --xAttr flag:

mount.flexfs start my-volume /mnt/data --xAttr

Xattrs are automatically enabled when ACLs or root squashing are active.

Umask

The umask controls the default permissions for newly created files and directories. FlexFS supports overriding the process umask at the mount level:

mount.flexfs start my-volume /mnt/data --umask 0027

This sets newly created files to 0640 and directories to 0750 regardless of the creating process’s umask. Umask can also be configured as a volume-level setting.

Volume-level flags

Several access control settings can be enforced at the volume level via configure.flexfs. When set on the volume, they apply to all mounts regardless of the mount client’s flags:

Volume flag	Effect
acl	Enable extended ACLs (implies xattr)
noexec	Prevent execution of files
nosuid	Disable SUID/SGID special permissions
ro	Read-only — no writes permitted
rootsquash	Enable root squashing (implies acl)
rootsquashgid=N	GID to map root to when rootsquash is set
rootsquashuid=N	UID to map root to when rootsquash is set
umask=NNNN	File creation mask in octal, with or without a leading 0 — 27 and 0027 mean the same thing; max 0777
xattr	Enable extended attributes

These flags are set during volume creation or update in configure.flexfs and override mount-client options. Additional non-access-control flags (e.g., caching, prefetching, proxy behavior) are also supported — see the full flag reference.

Volume token mount paths

Volume tokens can be scoped to a specific subdirectory within a volume. When a mount path is set on a token, the mount client only has access to that subdirectory and its contents — the rest of the volume is not visible.

This provides subdirectory isolation without creating separate volumes:

Volume: shared-data
  Token A (mount path: /team-alpha)   -> sees only /team-alpha/*
  Token B (mount path: /team-beta)    -> sees only /team-beta/*
  Token C (mount path: /)             -> sees entire volume

Mount path scoping is configured when creating or updating a volume token in configure.flexfs. The mount client automatically mounts at the scoped path.

Per-token mount flags

In addition to mount path scoping, each volume token can carry its own set of mount flags (e.g., ro, noExec). These flags are merged with the volume-level flags, providing token-level access control.

Immutable and append-only files

FlexFS supports the chattr(1) immutable (+i) and append-only (+a) inode flags on both files and directories. They differ from every other layer on this page in that they are not discretionary: an immutable file cannot be modified, deleted, renamed, or have its permissions changed even by root, until the flag is cleared. That makes them useful for pinning configuration or audit data against accidental change.

sudo chattr +i /mnt/flexfs/data/important.dat   # freeze
lsattr /mnt/flexfs/data/important.dat
sudo chattr -i /mnt/flexfs/data/important.dat   # release

Two limits matter for security planning. Setting a flag requires root as the mount sees it, so it is not possible on a --rootSquash mount. And enforcement is performed by the mount client, not the metadata server — the flags bind every caller reaching the data through a flexFS mount, but they are not a server-side retention or compliance control. See Inode flags for the full behavior.

Summary of access control layers

Layer	Scope	Configured via
POSIX permissions	Per-file/directory	Standard Unix tools (chmod, chown)
Extended ACLs	Per-file/directory	setfacl / getfacl
Immutable / append-only flags	Per-file/directory	chattr / lsattr
Root squashing	Per-mount or per-volume	--rootSquash flag or volume flag
Umask	Per-mount or per-volume	--umask flag or volume setting
Volume flags	Per-volume	configure.flexfs
Token mount paths	Per-token	configure.flexfs
Token flags	Per-token	configure.flexfs

Next steps

• Authentication — token model
• TLS Certificates — in-transit encryption
• End-to-end Encryption — data-at-rest encryption