How to explain NFS crossmnt argument?

Understanding the NFS crossmnt Export Option

Explore the purpose and implications of the crossmnt argument in NFS exports, how it affects client access to nested mounts, and best practices for its use.

When configuring Network File System (NFS) exports, you encounter various options that dictate how clients can access shared directories. One such option, often a source of confusion, is crossmnt. This article delves into what crossmnt means, why it's used, and how it impacts the client's view of your NFS server's file system.

The Basics of NFS Exports and Mount Points

Before understanding crossmnt, it's crucial to grasp how NFS handles mount points. An NFS server exports specific directories, making them available to clients. When a client mounts an exported directory, it sees only the content within that directory and its subdirectories. If a subdirectory within the exported path is itself a separate mount point on the server (e.g., a different partition or a bind mount), the client will not automatically see the content of that nested mount point by default.

flowchart TD
    subgraph NFS Server
        A[Root Filesystem /] --> B[/home]
        B --> C[/home/user1]
        B --> D[/home/user2]
        E[Separate Partition /data]
        B -- Mount Point --> E
    end

    F[NFS Client] -- Mounts /home --> G[/mnt/nfs/home]
    G -- Sees --> C
    G -- Sees --> D
    G -- Does NOT see --> E

Default NFS behavior without crossmnt

In the diagram above, if the NFS server exports /home, and /home/data is a separate mount point (e.g., a different disk partition) on the server, a client mounting /home will see /home/user1 and /home/user2, but it will not see the contents of /home/data. Instead, it will see an empty directory or whatever was originally at /home/data before the separate partition was mounted there on the server.

What crossmnt Does

The crossmnt option changes this default behavior. When crossmnt is specified for an exported directory, it tells the NFS server to automatically export any other local file systems that are mounted within the exported directory's hierarchy. This means that if /home is exported with crossmnt, and /home/data is a separate mount point on the server, the client will be able to traverse into /home/data and see its contents, provided /home/data is also explicitly exported or implicitly exported by crossmnt.

flowchart TD
    subgraph NFS Server
        A[Root Filesystem /] --> B[/home]
        B --> C[/home/user1]
        B --> D[/home/user2]
        E[Separate Partition /data]
        B -- Mount Point --> E
    end

    F[NFS Client] -- Mounts /home (with crossmnt) --> G[/mnt/nfs/home]
    G -- Sees --> C
    G -- Sees --> D
    G -- Also sees --> E

NFS behavior with crossmnt

Essentially, crossmnt allows clients to 'cross' the server's internal mount point boundaries. Without it, each mount point on the server that you want clients to access must be explicitly exported as a separate entry in /etc/exports and mounted separately by the client. With crossmnt, the client can mount a single parent directory and then navigate into its nested mount points as if they were regular subdirectories, without needing to perform additional mounts.

Configuring crossmnt in /etc/exports

To enable crossmnt, you simply add it to the options list for the parent directory in your /etc/exports file. Remember that for the nested mount points to be accessible, they must also be valid exportable paths on the server. The crossmnt option primarily affects how the client sees and traverses these nested mounts, not whether they are inherently exportable.

# /etc/exports on NFS Server
/home *(rw,sync,crossmnt)
/home/data *(rw,sync)

Example /etc/exports configuration with crossmnt

In this example, /home is exported with crossmnt. If /home/data is a separate mount point on the server, a client mounting /home will be able to access /home/data as well. Note that /home/data is also explicitly exported. While crossmnt helps with traversal, it's generally good practice to explicitly export the nested mount points if you intend for them to be accessed, especially if they have different access permissions or options.

Implications and Use Cases

The crossmnt option is particularly useful in scenarios where you have a complex file system layout on the server with multiple mount points nested under a common parent directory, and you want clients to perceive this as a single, unified file system tree. This simplifies client-side mounting, as they only need to mount the top-level directory.

Common use cases include:

• Homogeneous environments: Where all clients are trusted and you want to present a consistent view of the server's storage.
• Simplified client configuration: Reducing the number of mount commands or entries in /etc/fstab on client machines.
• Container environments: Where a single NFS mount might need to expose several underlying storage volumes from the host.

Client-Side Perspective

From the client's perspective, when crossmnt is in effect, navigating into a nested mount point feels seamless. The client's kernel handles the transition without requiring a separate mount operation for the nested directory. This is because the NFS server, upon receiving a request to access a directory that is a mount point, will respond with a special file handle that allows the client to 'follow' the server's internal mount point.

To verify the behavior on the client, you can use the mount command or df -h to see the mounted file systems. When crossmnt is used, you will typically only see the top-level mount, but you will be able to cd into the nested mount points.

# On NFS Client
mount -t nfs nfsserver:/home /mnt/nfs/home
cd /mnt/nfs/home/data
ls -l

df -h | grep /mnt/nfs/home

Client-side commands to test crossmnt behavior