Learn LXC - Binding & Mounting Host Paths

#Introduction

Containers have their own filesystem (rootfs), but sometimes they need data from the host: a project directory under development, a shared data volume between containers, or config managed from outside. In episode 11 we use bind-mounts — mounting host directories into the container — via lxc.mount.entry. This is the feature that makes LXC feel like "a real machine that can share disks".

#The Bind Mount Concept

A bind mount makes a host directory "stick" to another location inside the container's filesystem, without copying data. Both sides see the same files — a change on one side is immediately visible on the other. Think of it like a hard link for an entire directory: one data, two access doors.

Its strengths: no data duplication, no synchronization to maintain. Its drawback: you have to be careful with permissions and with what you share.

#Configuring lxc.mount.entry

Bind mounts are declared in the container config:

Let's break down the format (similar to the columns in /etc/fstab):

source — the host path (/srv/data).
mountpoint — the destination inside the container. The format can be c1/srv/data (relative to the rootfs) or ../.. for rootfs paths.
fstype — none for bind.
options — bind for a regular mount, bind,ro for read-only.
dump and fsck — 0 columns (ignored).

After editing the config, restart the container so the mount takes effect:

Apply the mount

lxc-stop -n c1
lxc-start -n c1

Verify from inside the container:

Check the mount is attached

lxc-attach -n c1 -- mount | grep srv
lxc-attach -n c1 -- ls /srv/data

Tip

Use the bind,ro option for anything the container shouldn't modify — e.g. config, binaries, or reference data. A read-only mount protects against accidental damage and against interference from hijacked processes inside the container.

#Real-World Use Cases

The most common example: sharing a data directory between containers, or keeping data on the host disk for easy backup.

Two containers (e.g. web and worker) can share the same /srv/uploads — data is written once, and both read the same files.

Share config managed from the host, or binaries/tooling so they don't need to be installed in every container:

Sharing config read-only

lxc.mount.entry = /srv/conf/nginx.conf c1/etc/nginx/nginx.conf none bind,ro 0 0

#Device Access from the Container

Host devices can also be mounted into the container. For access to a single device (e.g. a particular USB serial):

The create=file option creates the device node in the container if it doesn't exist. For broader device passthrough cases (GPU/USB), we cover that in episode 14.

Warning

Mounting host devices into a container loosens isolation: a rooted, compromised process inside the container can write to that device. Never bind-mount a device without understanding the risk, and combine it with cgroup device limits (episode 14) for truly controlled access.

#Permissions and Pitfalls

#UID Issues

This is a classic LXC pitfall: bind-mounts follow the host UID, not the container UID. Files in /srv/data owned by UID 1000 (a host user) will appear owned by UID 1000 inside the container. On an unprivileged container, container UIDs are mapped — e.g. container UID 0 = host UID 100000 — so permissions that match on the host won't necessarily match inside the container.

Practical solutions:

Create the directory on the host with permissions matching the UID of the process inside the container.
For unprivileged containers, use the UID corresponding to the idmap mapping (episode 15).
For sharing files with regular users, create a shared group on the host and set setgid.

#Path Doesn't Exist

If the mountpoint directory inside the container doesn't exist, the mount fails. Create it first:

Create the mountpoint inside the container

lxc-attach -n c1 -- mkdir -p /srv/data

#Mount Doesn't Appear

If the bind mount isn't visible after a restart, check the config syntax and the container log:

View the container log

cat /var/lib/lxc/c1/log/lxc.log | tail -30

#Closing

Key takeaways:

Bind mounts connect host and container directories without copying data.
lxc.mount.entry format: source, mountpoint, fstype, options, dump, fsck.
bind,ro locks a directory read-only — the safe default for config/reference data.
Common cases: sharing data between containers, sharing config, and device access.
Pay attention to UID mapping on unprivileged containers — this is the most frequent source of permission errors.

In the next episode 12 we'll cover containers in Proxmox VE — how PVE uses LXC as its CT engine, the fact that PVE 9.2 ships LXC 7.0 LTS, unprivileged CT as the default, and the practices of Docker-in-LXC and nested virtualization.