Home / Alt manpages / proc_sys_user(5)

  • proc_sys_user(5)
  • File format
  • linux

Set Safe Per-User Namespace Limits with /proc/sys/user

A container build fails with ENOSPC from clone() while disk space is fine: that is /proc/sys/user reporting an exhausted namespace limit. This guide inspects the namespace limits enforced by this Linux host, matches the limit to the failing operation, and changes one value temporarily or persistently with a rollback plan ready.

Allow about ten minutes. You need a shell for inspection; changing a value needs the privilege accepted by your host's procfs policy.

This follows the installed proc_sys_user(5) manual from man-pages 6.7, package version 6.7-2. The examples run on Linux 6.8.0-139-generic. Kernel versions and distributions can expose a different set of files, so inspect the directory rather than copying a fixed list blindly.

1. Read the limits in the current user namespace

Start with the directory itself. Reading these pseudo-files is ordinary and non-destructive, and does not need sudo:

$ printf '%s\n' /proc/sys/user/max_*_namespaces
/proc/sys/user/max_cgroup_namespaces
/proc/sys/user/max_ipc_namespaces
/proc/sys/user/max_mnt_namespaces
/proc/sys/user/max_net_namespaces
/proc/sys/user/max_pid_namespaces
/proc/sys/user/max_time_namespaces
/proc/sys/user/max_user_namespaces
/proc/sys/user/max_uts_namespaces

$ for file in /proc/sys/user/max_*_namespaces; do
    printf '%-32s %s\n' "${file##*/}" "$(cat "$file")"
  done
max_cgroup_namespaces             127192
max_ipc_namespaces                127192
max_mnt_namespaces                127192
max_net_namespaces                127192
max_pid_namespaces                127192
max_time_namespaces               127192
max_user_namespaces               127192
max_uts_namespaces                127192

Your values will differ. These files limit how many namespaces of the named type each user in the relevant user namespace may create. They are not a count of namespaces currently in use, and they grant no permission to create one; other kernel checks and resource limits still apply.

Checkpoint

Save the relevant current value before changing anything:

$ old_value=$(cat /proc/sys/user/max_user_namespaces)
$ printf 'current max_user_namespaces: %s\n' "$old_value"
current max_user_namespaces: 127192

2. Map the failure to the matching file

Use the namespace type named in the failing operation. A user namespace is governed by max_user_namespaces; a PID namespace by max_pid_namespaces; a mount namespace by max_mnt_namespaces, and so on. The installed namespaces(7) manual lists cgroup, IPC, mount, network, PID, time, user and UTS namespace limits.

When one of these limits is reached, clone(2) or unshare(2) fails with ENOSPC. That error means a namespace limit may be exhausted, not that the disk is full. Check the calling program's complete error message and confirm which type it is actually creating.

These limits are per user and apply to UID 0 as well, on top of any other per-namespace limits. A high value cannot make an otherwise forbidden or unsupported namespace operation succeed.

3. Confirm which user namespace the process sees

The value exposed by these files belongs to the user namespace the reading process lives in. A container or sandbox can show a different value from the host. Check the process's namespace identity before comparing results between shells:

$ readlink /proc/self/ns/user
user:[4026531837]
$ sysctl user.max_user_namespaces
user.max_user_namespaces = 127192

The numeric ID is host-specific, and useful mainly for proving that two commands run in different user namespaces. The installed sysctl command comes from procps 2:4.0.4-4ubuntu3.3 and reads the same kernel interface; direct reads are equally valid.

4. Make a temporary, reversible test change

Warning

Lowering a limit can stop containers, sandboxes or build tools from creating new namespaces. Raising it can allow more per-user kernel objects and may increase resource pressure. Do not change a production host during an active deployment without checking which workloads depend on namespace creation.

Choose a deliberately modest test value and record the old value first. This changes only the live kernel setting and does not edit a configuration file:

$ old_value=$(cat /proc/sys/user/max_user_namespaces)
$ printf '%s\n' 4096 | sudo tee /proc/sys/user/max_user_namespaces
4096
$ cat /proc/sys/user/max_user_namespaces
4096

sudo is shown because an unprivileged write normally fails; use whatever privilege mechanism is approved for your system. The write affects the user namespace of the opening process. It is not a service restart, but it changes the limit immediately for new namespace creation attempts.

Restore the exact previous value once the test is over:

$ printf '%s\n' "$old_value" | sudo tee /proc/sys/user/max_user_namespaces
127192
$ test "$(cat /proc/sys/user/max_user_namespaces)" = "$old_value" && echo restored
restored

If the shell holding old_value has gone away, read the current setting and restore the value from your own change record. Do not guess: a temporary procfs write normally does not survive a reboot.

5. Make a persistent change only after testing

Once the value has been tested and reviewed, put the setting in the sysctl configuration mechanism your distribution uses. The exact file is distribution policy, not a property of proc_sys_user(5). On systems using /etc/sysctl.d/, a root administrator might create a narrowly named file such as /etc/sysctl.d/60-namespace-limits.conf containing:

user.max_user_namespaces = 4096

Security boundary

This is a security-sensitive configuration change. Keep the old value in version control or a change record, and review the file for duplicate settings before applying it. Apply it through the normal system procedure, then verify the live value:

# sysctl --system
# sysctl user.max_user_namespaces
user.max_user_namespaces = 4096

The output of sysctl --system varies by distribution and may show other files being read. If you remove the persistent setting later, reload the intended replacement value explicitly and confirm no earlier file still overrides it: removing a file alone does not automatically restore the previous live value until the next reload or reboot.

Common traps

  • Treating a large number as usage. These files expose limits, not counts of what is already allocated.
  • Assuming every machine has every file. Linux adds namespace types over time, and a container may expose a restricted view.
  • Equating ENOSPC with disk space. Check the failing namespace operation and its matching limit first.
  • Using sudo for read-only inspection. Save elevated privilege for an intentional write or a system-wide reload.
  • Confusing this with cgroup limits. These cap namespace creation; they do not replace CPU or memory resource management.

Done means

  • Listed the limits. You listed the namespace limit files visible from the relevant user namespace.
  • Matched the failure. You matched the failing operation to the correct max_*_namespaces file.
  • Recorded before writing. You captured the old value before any write and verified the new one afterwards.
  • Restored or documented. A temporary test was restored, or a persistent change has a recorded rollback value.
  • Kept expectations realistic. You have not assumed a namespace limit increase bypasses other kernel or security checks.