Troubleshooting

ptrace(PTRACE_SEIZE) refused: this process is already traced

You are starting proot-next under a debugger, or under a supervisor other than proot-next (the original PRoot, for instance). Inside proot-next itself this does not happen: an exec of proot or bwrap is served as a nested launch with a view of its own, see how it works. Open a fresh terminal.

In bwrap mode the same situation reads bwrap: No permissions to create a new namespace: proot-next cannot run under another supervisor and exits 1, the wording that programs looking for bubblewrap (GTK's glycin image loaders, WebKit) take as "no sandbox here" before carrying on without one.

cannot reach the guest's memory

The kernel refused proot-next access to its own child, both as it is and inside a user namespace, and both modes need that access. The message names the kernel.yama.ptrace_scope setting. Any one of these fixes it:

• kernel.yama.ptrace_scope of 0 or 1 on the host (2 alone is handled by a user namespace, 3 cannot be lowered until reboot).
• Unprivileged user namespaces: in a container, a seccomp profile that allows unshare (Kubernetes seccompProfile: Unconfined or a Localhost profile; Docker --security-opt seccomp=unconfined).
• CAP_SYS_PTRACE that is effective, which in a container means running as root with the capability added; adding it to a non-root user's container only raises the bounding set.
• On x86_64 and aarch64, the guest-stub mode, which needs none of the above and is the fallback unless PROOT_GUEST_STUB=0 rules it out, so this message only appears with that setting or on other architectures.

In bwrap mode the message starts with bwrap: No permissions to create a new namespace:, so callers looking for bubblewrap carry on without a sandbox. The exit status is 1 either way.

-0 inside proot-next needs the outer proot started with -0

A nested launch asked for fake root (or -k), which adds syscalls to the seccomp filter, and the filter is fixed when the outer proot starts. Start the outer one with the same option.

A container whose seccomp profile filters the ptrace syscall does not reach this message: proot-next notices at start-up and runs without the ptrace tier. PROOT_NO_PTRACE=1 selects that mode by hand; proot -v 1 (or PROOT_VERBOSE=1) says running without ptrace when it is in effect.

cannot install the exec shim

Without ptrace, an exec goes through a small static program that proot-next writes under $XDG_RUNTIME_DIR, then $TMPDIR, then ~/.cache. Every candidate was on a noexec mount or not writable. Point XDG_RUNTIME_DIR at a directory where programs may run.

proot: exec shim: cannot execute ...

The trampoline could not exec the real program: the message carries the errno. The process exits 126, or 127 for a missing file, as a shell would.

seccomp user notification is not available on this kernel or is filtered

The kernel is older than 5.0, or a seccomp policy outside Docker's default blocks the listener flag of the seccomp syscall.

A program sits there doing nothing

Run with PROOT_VERBOSE=2 (or -v 2) and look at the last translation before silence. A request that is never answered is a bug here; report it with those lines.

Something under Steam restarts every ten seconds

The Steam client restarts its browser helper on a ten-second deadline. Set PROOT_VERBOSE=1 in Steam's environment; fatal signals are reported with the module and offset they happened at, in ~/.local/share/Steam/logs/webhelper-linux.txt.

The supervisor is at 100% CPU

It should never be. Capture the per-thread state and report it:

for t in /proc/PID/task/*; do echo "$(cat $t/comm) $(cat $t/wchan)"; done