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

You will inspect the namespace limits enforced by this Linux host, identify the limit that affects a failing namespace operation, and change one value temporarily or persistently with a rollback plan. Allow about ten minutes. You need a shell for inspection; changing a value requires the privilege accepted by your host's procfs policy.

This guide follows the installed proc_sys_user(5) manual from man-pages 6.7, package version 6.7-2. The machine used for the examples runs 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 an ordinary, non-destructive operation 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. The 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 do not grant permission to create one. Other kernel checks and resource limits still apply.

$ 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 a failure to the matching file

Use the namespace type in the operation that failed. 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, the clone(2) or unshare(2) operation fails with ENOSPC. That error means the namespace limit may be exhausted, not that the disk is full. Check the calling program's complete error message and confirm that it is creating the type you think it is creating.

These limits are per user, and they apply to UID 0 as well. They also apply in addition to other per-namespace limits. A high value therefore cannot make an otherwise forbidden or unsupported namespace operation succeed.

3. Confirm which user namespace the process sees

The value exposed by these files is associated with the user namespace in which the process opening the file resides. A container or sandbox can therefore 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. It is useful when you need to prove that two commands are running in different user namespaces. The installed sysctl command comes from procps 2:4.0.4-4ubuntu3.3 and uses the same kernel interface here; direct reads are equally valid.

4. Make a temporary, reversible test change

Choose a deliberately modest test value and record the old value first. This example 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 the privilege mechanism approved for your system. The write affects the user namespace associated with 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 when 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 that stored old_value has gone away, read the current setting and restore the value from your 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 used by your distribution. 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

This is a security-sensitive configuration change. Keep the old value in version control or an administrator's 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 from 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 that no earlier file still overrides it. Removing a file alone does not necessarily restore the previous live value until the next reload or reboot.

6. Avoid the common diagnosis traps

• Do not treat a large number as the number of namespaces already allocated. The files expose limits.
• Do not assume every machine has every file. Linux adds namespace types over time, and a container may expose a restricted view.
• Do not equate ENOSPC with storage exhaustion without checking the failing namespace operation and the matching limit.
• Do not use sudo for read-only inspection. Use elevated privilege only for an intentional write or for a system-wide configuration reload.
• Do not confuse these limits with cgroup CPU or memory controls. They cap namespace creation; they do not replace resource management.