Using Linux Bind Mounts to Expose SMB Subdirectories with Restricted Permissions

When working with SMB shares on Linux, it is sometimes useful to expose the same remote data at multiple local paths. You might also want one path to remain read/write while applications see only selected subdirectories as read-only.

Linux bind mounts are a clean way to do this.

Mounting the same SMB share more than once

Linux can mount the same SMB/CIFS share at multiple mount points:

sudo mount -t cifs //10.0.0.150/Music /mnt/navidrome \
  -o credentials=/root/.smbcredentials

sudo mount -t cifs //10.0.0.150/Music /mnt/mp3 \
  -o credentials=/root/.smbcredentials

Both paths expose the same files on the remote server:

/mnt/navidrome/Artist/Album/song.mp3
/mnt/mp3/Artist/Album/song.mp3

This works, but it creates two separate CIFS mounts. If both paths should expose the same data with mostly the same mount options, a bind mount is often simpler.

What is a bind mount?

A bind mount takes an existing directory and exposes it at another location in the Linux filesystem.

For example:

sudo mount --bind /mnt/navidrome /mnt/mp3

After that, both paths refer to the same underlying files:

/mnt/navidrome/Artist/Album/song.mp3
/mnt/mp3/Artist/Album/song.mp3

There is no copy involved. Changes made through one path affect the same files visible through the other path.

Conceptually:

//10.0.0.150/Music
        │
        │ CIFS
        ▼
 /mnt/navidrome
        │
        │ bind mount
        ▼
    /mnt/mp3

Unlike a symbolic link, the second path behaves like a mounted filesystem location. This makes bind mounts especially useful for containers, media servers, chroots, and applications that expect real filesystem paths.

You can inspect a bind mount with:

findmnt /mnt/mp3

and unmount it independently:

sudo umount /mnt/mp3

The original mount remains available.

Making a bind mount read-only

A bind mount initially exposes the same data with the same underlying Unix ownership and permissions. However, the bind-mounted view itself can be made read-only.

First create the bind mount:

sudo mount --bind /mnt/navidrome /mnt/mp3

Then remount the bind mount as read-only:

sudo mount -o remount,bind,ro /mnt/mp3

The result is:

/mnt/navidrome   read/write
/mnt/mp3         read-only

Applications using /mnt/mp3 cannot modify files through that path, while administrative tools can still modify the same files through /mnt/navidrome.

Additional mount restrictions can also be useful:

sudo mount -o remount,bind,ro,nosuid,nodev,noexec /mnt/mp3

The relevant options are:

• ro: read-only
• nosuid: ignore setuid and setgid bits
• nodev: do not interpret device files
• noexec: prevent binaries from being executed through this mount

For media directories, ro,nosuid,nodev is often a sensible baseline. noexec can also be useful if nothing needs to be executed from the directory.

Bind mounting only part of an SMB share

Bind mounts do not need to expose the root of another mount. Any subdirectory can be bind mounted independently.

Suppose the NAS contains:

//10.0.0.150/Public
├── Music
├── Video
└── Photo

Mount the complete share once with read/write access:

sudo mkdir -p /mnt/public-data

sudo mount -t cifs //10.0.0.150/Public /mnt/public-data \
  -o credentials=/root/.smbcredentials

The local tree now looks like:

/mnt/public-data
├── Music
├── Video
└── Photo

Create separate mount points:

sudo mkdir -p /mnt/Music /mnt/video /mnt/Photo

Then bind mount each subdirectory:

sudo mount --bind /mnt/public-data/Music /mnt/Music
sudo mount --bind /mnt/public-data/Video /mnt/video
sudo mount --bind /mnt/public-data/Photo /mnt/Photo

Make each view read-only:

sudo mount -o remount,bind,ro /mnt/Music
sudo mount -o remount,bind,ro /mnt/video
sudo mount -o remount,bind,ro /mnt/Photo

The resulting layout is:

//10.0.0.150/Public
        │
        │ CIFS, read/write
        ▼
 /mnt/public-data
     ├── Music ──────► /mnt/Music  read-only
     ├── Video ──────► /mnt/video  read-only
     └── Photo ──────► /mnt/Photo  read-only

This provides one administrative read/write mount while exposing restricted paths to individual services.

For example, a media server could use /mnt/Music without having write access through that path, while file-management tools continue to use /mnt/public-data.

Persistent configuration with /etc/fstab

The same setup can be made persistent.

First mount the SMB share:

//10.0.0.150/Public  /mnt/public-data  cifs  credentials=/root/.smbcredentials,_netdev  0  0

Then define the bind mounts:

/mnt/public-data/Music  /mnt/Music  none  bind,ro,nosuid,nodev  0  0
/mnt/public-data/Video  /mnt/video  none  bind,ro,nosuid,nodev  0  0
/mnt/public-data/Photo  /mnt/Photo  none  bind,ro,nosuid,nodev  0  0

This keeps the NAS connection centralized while presenting different parts of the share at convenient local paths.

What bind mounts do not change

A bind mount does not create a separate copy of the files and does not give them separate ownership.

For example, you cannot normally use a bind mount to make the same file appear as UID 1000 through one path and UID 2000 through another.

Both paths still reference the same inode and underlying filesystem metadata. Running chmod or chown through one path modifies the same file visible through the other path.

What bind mounts are well suited for is applying mount-level restrictions such as:

read/write source
        │
        ├── read-only view for Navidrome
        ├── read-only view for a video server
        └── read-only view for a photo application

Conclusion

For a NAS-backed media library, a useful pattern is:

1. Mount the SMB share once.
2. Keep that primary mount read/write for administration.
3. Bind mount selected subdirectories to application-specific paths.
4. Make those bind mounts read-only and optionally add nosuid, nodev, or noexec.

This avoids maintaining multiple SMB connections and gives applications clean, restricted filesystem views without duplicating any data.