Proxmox VE / Intermediate: data, identity and policy / Lesson 7

Container mounts and resource contracts

Evaluate container root filesystems, mount points and resource limits as explicit ownership and recovery decisions.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish managed volumes from bind and device mounts.
Trace mapped ownership into application access.
Separate resource ceilings from measured workload demand.

Inventory each data path

A container can use a managed root filesystem and additional mount points with different semantics. A storage-managed volume is not the same as a host bind mount or device mount. Those distinctions affect migration, backup inclusion, permissions and dependence on host paths. Record the application path, source identity, ownership model and recovery owner for each mount. A familiar directory name inside the container does not reveal where its bytes live. Before declaring a backup complete, compare the included managed volumes with every application data path rather than assuming all visible files belong to the archive.

Map application identity to files

An application process runs under a user and group identity that must align with mapped filesystem ownership. A permission failure can arise from a wrong source path, an ID mapping mismatch or missing access on a parent directory. Making everything world-writable conceals the contract and expands exposure. The first record uses synthetic paths only and asks which identity should own the data. Real ownership changes can affect host and container access simultaneously, so diagnose the mapping before planning any mutation. This course neither reads nor changes host paths or account databases.

text Mount ownership inventory

container path: /srv/catalog-data
source kind: externally managed bind mount
application identity: synthetic UID 1000
review: mapped host owner, parent permissions, backup owner, target-host path

These paths are illustrative text, not real locations inspected by the course.

Explain resource controls

CPU and memory controls limit or prioritize consumption through host-kernel mechanisms. A configured limit is not a reservation of all corresponding physical capacity, and a low limit can cause application stalls or termination. Memory, swap and cache accounting require careful interpretation rather than comparison with a single dashboard number. The second program computes a synthetic budget margin for three containers. It does not reproduce cgroup accounting. Use it to keep units and arithmetic explicit, then obtain actual working-set and pressure evidence in a separately authorized environment before selecting limits.

python Synthetic container budget ledger

budget_mib = 8192
planned_mib = [1024, 2048, 1536]
print(sum(planned_mib))
print(budget_mib - sum(planned_mib))

Expected output

4608
3584

4608 and 3584 are arithmetic results only. They are not host memory observations or admission recommendations.

Review feature expansion

Nesting, device exposure and additional mount permissions can make a container more flexible while increasing dependence on host capabilities. Treat each feature as a reviewed requirement, not a collection of switches to enable when an application fails. Some workloads fit a VM boundary better because they expect their own kernel or broad device access. Document why a container remains the selected boundary after the extra feature is considered. Also assess whether the configuration remains portable to another node; a mount tied to one host path can invalidate an otherwise reasonable migration plan.

Connect mounts to recovery

A recovery plan must reconstruct both the container definition and every required data source. Restoring a root filesystem while omitting an external mount can produce an apparently healthy container with missing business data. Confirm the intended mount source before allowing a restored application to initialize an empty directory, which could mask the omission. Define acceptable resource limits for recovery as well as normal operation. No container is created, started, mounted or restored here. The inventory and arithmetic establish only a reviewable model whose platform behavior and data correctness remain unexecuted.

Common errors and fixes

A restore omits data from a bind mount

Why it happens: Visible container files were assumed to be included in the managed backup.
How to fix it: Inventory the external data source and its independent recovery procedure.
Prevent it next time: Map every application path to backup ownership.

World-writable permissions conceal mapped-ID errors

Why it happens: Access was widened before identifying the application and host identities.
How to fix it: Review mapping, source path and required access precisely.
Prevent it next time: Keep ownership evidence with mount definitions.

A limit is treated as dedicated host memory

Why it happens: Resource controls were confused with capacity guarantees.
How to fix it: Assess working sets, host pressure and competing workloads separately.
Prevent it next time: Separate configured ceilings from measured usage.

Check your understanding

1. A restored container starts with an empty /srv/catalog-data. What should be established before initializing data?

Show worked solution

Determine whether the path should be a restored managed volume, external bind mount or another data source. Confirm its identity and recovery status with the data owner. An empty directory can mean a missing mount rather than a legitimately new application. Starting initialization too soon can conceal the error or create divergent state.

2. Why does a portable root filesystem not guarantee container migration portability?