Linux nosymfollow blocks one symlink path, not every path problem

Linux 5.10 introduced the MS_NOSYMFOLLOW mount flag, which stops symbolic links on a mount from being followed. This targeted control is useful for specific directories, such as static assets, upload directories, or areas where symlinks shouldn't act as escape routes. The mount option only changes path resolution on that mounted filesystem.

A path that crosses into another mount may behave differently. A symlink present before the mount or a directory reachable through another path may not be governed as expected. Thus, nosymfollow is best used as one layer in a file-serving design, not as a replacement for application-level path validation or a least-privileged service account.

The best candidates for this option are trees with simple contracts, like static asset directories containing regular files, upload directories storing user content, or package extraction areas that reject archive entries creating links outside the extraction root. The mount should have the smallest practical privilege set. Using a dedicated bind mount or mount namespace for the content tree ensures the option remains visible.

Testing should be performed on a controlled test directory, confirming that reading through the link fails while the regular file remains readable. The test should cover path traversal, hard links, and a second mount beneath the tree, recording kernel version, mount options, filesystem type, and service account used. The test results should be logged and monitored, as the control belongs to the data path owner, not just the security team.

No matter how useful, nosymfollow does not make untrusted file content safe, prevent parser vulnerabilities, hard-link attacks, or misleading file extensions. It only removes one way for a symlink on the mounted tree to change the path. Therefore, it's best used to remove a class of link-following mistakes without assuming every path is now safe.