FailFS entered the Linux 7.3 development cycle alongside fchroot(). It gives programs a way to shed ordinary filesystem starting points, but it is a building block for confinement rather than a complete sandbox.
Root and working directory have separate effects
The FailFS pull request introduces an internal filesystem that rejects operations reaching it with EOPNOTSUPP. Userspace cannot mount it as an ordinary filesystem. The special FD_FAILFS_ROOT value is understood by fchroot() and fchdir().
The current kernel documentation distinguishes the two transitions. Moving the root to FailFS blocks absolute-path lookups, including absolute symlinks and the interpreter path of dynamically linked executables. Moving the working directory blocks relative lookups anchored at AT_FDCWD. Changing only one does not automatically change the other.
Lookups using retained directory descriptors still work. A descriptor to a directory provides authority to perform further path operations, not merely access to one previously opened file. The diagram shows these surviving paths explicitly.
Unprivileged entry requires more than one flag
For unprivileged fchroot() entry into FailFS, the documentation requires no_new_privs, a caller that is not already chrooted, and an unshared filesystem state. The original article mentioned only no_new_privs and therefore omitted conditions that can make a call fail.
The reason for the existing-chroot restriction is especially useful: directory descriptors and parent traversal can undermine assumptions about confinement when the root is changed. Review every retained descriptor and the path-resolution policy, not just absolute pathnames. Network access and other capabilities are separate controls.
The documentation also says that difficulty leaving FailFS is a property of the current implementation, not a promised permanent interface. Do not describe entry as universally irreversible. A test design should cover root-only, cwd-only and both transitions, explicit directory lookups, dynamic execution and expected entry failures. These are proposed cases, not kernel tests run by PeopleAreGeek.
Two old filesystem drivers were removed separately
The EFS removal concerns the old SGI IRIX on-disk format. It is unrelated to Amazon Elastic File System. The FreeVxFS removal removes the legacy Veritas-format reader.
If an archive depends on either reader, preserve a known-working recovery environment and work from a copy of the media. A newer kernel lacking the driver does not erase the stored data, but it changes the tools available to recover it. Check the actual distribution kernel and configuration; the upstream development change is not an immediate switch applied to every installed Linux system.
Separate root and cwd effects, add all unprivileged-entry conditions, explain retained directory authority and non-guaranteed irreversibility; document EFS versus Amazon EFS.