# Prerequisites Alpine Linux Edge

~ $ podman --version
podman version 5.5.2
~ $ distrobox --version
distrobox: 1.8.1.2
~ $ mount|grep ^cgroup|awk '{print $1}'|uniq
cgroup2

I followed the steps in Alpine Wiki for setting up distrobox and podman for rootless usage. # What is happening The block bellow is the primary issue I'm running into.

~ $ distrobox create --name debox --image debian:latest
Creating 'debox' using image debian:latest	[ OK ]
Distrobox 'debox' successfully created.
To enter, run:

distrobox enter debox

~ $ distrobox enter debox
Error: unable to start container "409500222cb9ecfb488522e1d0a13046e68408fcb62a9dcfb52ae88bda0816c0": runc: runc create failed: unable to start container process: unable to apply cgroup configuration: rootless needs no limits + no cgrouppath when no permission is granted for cgroups: mkdir /sys/fs/cgroup/409500222cb9ecfb488522e1d0a13046e68408fcb62a9dcfb52ae88bda0816c0: permission denied: OCI permission denied

I've attempted to create the folder distrobox tries to create and give my user complete permissions to use it to no avail. The same error occurs. Launching this container with just podman will output the same error. Meanwhile, starting similar container with podman seamingly works.

~ $ distrobox rm debox
# output omitted
~ $ podman create --name debox -i debian:latest
62f2044c8bb7e86b4a78bd48e7f0c66c1071924a3bc65c0d49519ca399753d9c
~ $ podman start debox
debox

As indicated by podman stats the container is up and running:

ID            NAME        CPU %       MEM USAGE / LIMIT  MEM %       NET IO      BLOCK IO           PIDS        CPU TIME         AVG CPU %
62f2044c8bb7  debox       23.49%      0B / 7.182GB       0.00%       0B / 796B   2.876GB / 1.516GB  0           1h22m26.154492s  6227.30%

It starts with showing impossibly high CPU percentage hence, the high average CPU use. Probably, irrelevant to issue. After attaching to container there is no prompt. Detaching to exit via ctrl+p, ctrl+q is impossible. Attempting to stop container will force podman to resort to SIGKILL. Container will not appear in podman ps afterwords (it did before) but, still can be launched but, the same as above will repeat:

~ $ podman stop debox
WARN StopSignal SIGTERM failed to stop container debox in 10 seconds, resorting to SIGKILL 
debox
~ $ podman ps
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
~ $ podman start debox
debox

# What I want Just distrobox enter debox and use container as intended.

This is certainly a niche use-case, so I ask you to bear with me. My goal is to run a proprietary application within Distrobox. I don't want to expose my local username (reused online) to said application, hence I'm trying to run this as a different local user. ### Starting point ### It's already possible to run application on host as different user, even if it's not the most secure method in the world, thanks to [this answer by Sam Mason](https://unix.stackexchange.com/a/791365/8305) . To summarize, assuming the secondary, non-session username is other, you need to do the following:

$ sudo chown :other "$XDG_RUNTIME_DIR" "$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY"
$ chmod g+rwx "$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY"
$ chmod g+x "$XDG_RUNTIME_DIR"
$ machinectl shell \
  --setenv=WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" \
  --setenv=XDG_SESSION_TYPE \
  other@

And with just that, you can run any Wayland application within the context of the other user in your current session. ### XWayland works too ### With a few additions to the above method, you can get X applications (such as Steam and myriad other Electron crapware) to run as the other user:

$ xhost +local:
$ machinectl shell \
  --setenv=WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" \
  --setenv=XDG_SESSION_TYPE \
  --setenv=DISPLAY \
  other@

**Disclaimer** I don't understand the security implications of xhost (or assigning those permissions to the $WAYLAND_DISPLAY) and if there are safer alternatives, whether better permissions or different method entirely. If you want to use this method, do so at your own risk. The xhost command is a suggestion from [this guide](https://www.siberoloji.com/how-to-use-distrobox-for-containerized-apps-on-arch-linux/#7-running-gui-applications-from-the-container) . ### The problem with Wayland in another user's Distrobox ### As I mentioned above, using this method applications run perfectly fine whether Wayland or XWayland. When it comes to Distrobox, however, only the X applications run fine. Any Wayland application within Distrobox (and running as different user) refuses to start and always crashes with some variant of unable to open display errors. How do I go about debugging this issue? How come passing DISPLAY work perfectly, but fail with WAYLAND_DISPLAY? Any hint would be appreciated. As I mentioned before, this is a niche edge case. I don't expect solutions outright, Just showing me potential path forward would be much appreciated. **PS** As an aside, theoretically there might be a way to accomplish my original goal (not exposing my local username to Distrobox) without going through such rigmarole. When initializing a Distrobox container, it [actually creates an user](https://distrobox.it/usage/distrobox-init/) within it with the same name as the local username and assigns the same UID and GID. If Distrobox would just let the username variable to be set manually, it'd probably do exactly what I want... It's as frustrating as you might imagine. I asked if there's anyway for me to modify it on [GitHub issues](https://github.com/89luca89/distrobox/issues/1783) , but I'm suffering in silence.