Distrobox not usable in current state

I have the same problem as posted here:

I don’t understand what’s the supposed solution. My system works fine and sudo works normally. The Distrobox Wiki entry doesn’t even mention the issue, much less any kind of solution.

As of today, any distrobox image I create is useless.
Thanks for any guidance.

Are you using Podman or Docker as the container manager ?
Not sure if I can help, but that information will be useful for everyone else.

I had my own permission problems with Docker in the past and therefore switched to Podman.
Note also that it is not that straight forward to switch; I just completely uninstalled Docker because I wasn’t using it anymore.

I’m using Docker because I’m 95% certain Distrobox has it as a dependency.

@lavadrop podman… no docker installed here…

Distrobox is perfectly happy with either Podman or Docker, it doesn’t care.

As others have stated, Distrobox can use a variety of container managers, but I am quite certain that Podman is the recommended one. Have a look at this:

Can we go back to the main topic of why openSUSE Tumbleweed + Distrobox + Docker stopped working and how to fix it?

@lavadrop AFAICT it’s still an ongoing bug https://github.com/89luca89/distrobox/issues/1092

I would suggest adding voice there.

Thank you, I’ll add my voice in hopes they reopen the report.

Same here on a fresh Tumbleweed installation. I create a distrobox container with:

distrobox create -i ubuntu:24.04 -n colmap

However inside the container I am unable to use neither sudo nor su.

$ sudo apt update
[sudo] password for ...: 
... is not in the sudoers file.

$ su
Password: 
su: Authentication failure

So add your user to the sudoers, or add your users to the wheel or sudo group, where is the problem?

That is what Ubuntu does by default. It has nothing to do with distrobox.

It has everything to do with Distrobox since it used to work just as expected on openSUSE before December 2023. I had it running before I had to reinstall openSUSE. Even @pavinjoseph sent a commit with a fix that didn’t work.

In order to add my user to sudo group I need to have sudo access in the first place.

It used to work for me too until I reinstalled Tumbleweed.

The distrobox issue linked earlier provides instructions how to enter root shell.

podman exec -it <name-of-your-container> bash

or

docker exec -it <name-of-your-container> bash
1 Like

Thanks so much, this is a good workaround for the time being!

It would be much more useful if you described step by step how to reproduce this issue. Because it most certainly works here on the latest Tumbleweed.

andrei@tumbleweed:~> distrobox create -i tumbleweed:latest
Resolved "tumbleweed" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.opensuse.org/opensuse/tumbleweed:latest...
Getting image source signatures
Copying blob e2adb880de5c skipped: already exists
Copying config e2e6403440 done   |
Writing manifest to image destination
e2e64034402d78deed319cabd9f1a3b5bdd6ef6a95a89654bfbef225554e3442
Creating 'tumbleweed' using image tumbleweed:latest     Resource limits are not supported and ignored on cgroups V1 rootless systems
 [ OK ]
Distrobox 'tumbleweed' successfully created.
To enter, run:

distrobox enter tumbleweed

andrei@tumbleweed:~>

andrei@tumbleweed:~> distrobox enter tumbleweed
Starting container...                            [ OK ]
Installing basic packages...                     [ OK ]
Setting up devpts mounts...                      [ OK ]
Setting up read-only mounts...                   [ OK ]
Setting up read-write mounts...                  [ OK ]
Setting up host's sockets integration...         [ OK ]
Integrating host's themes, icons, fonts...       [ OK ]
Setting up package manager exceptions...         [ OK ]
Setting up rpm exceptions...                     [ OK ]
Setting up distrobox profile...                  [ OK ]
Setting up sudo...                               [ OK ]
Setting up user groups...                        [ OK ]
Setting up kerberos integration...               [ OK ]
Setting up user's group list...                  [ OK ]
Setting up existing user...                      [ OK ]
Setting up user home...                          [ OK ]
Ensuring user's access...                        [ OK ]

Container Setup Complete!
📦[andrei@tumbleweed ~]$ sudo ls
bin  cache  du  openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64.raw  tmp
📦[andrei@tumbleweed ~]$

And it works even with rootful container

andrei@tumbleweed:~> distrobox create -i tumbleweed:latest --root
...
andrei@tumbleweed:~> distrobox enter --root tumbleweed
...
Ensuring user's access...                        [ OK ]

Container Setup Complete!
⚠️  First time user password setup ⚠️
New password:
Retype new password:
passwd: password updated successfully
📦[andrei@tumbleweed ~]$ sudo ls

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

For security reasons, the password you type will not be visible.

[sudo] password for andrei:
bin  cache  du  openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64.raw  tmp
📦[andrei@tumbleweed ~]$

OK, it is not a bug, it is a feature. In rootful mode distrobox follows host settings, meaning - it only adds user to wheel/sudo in container if user is already in wheel/sudo on host.

# If we're rootful, search for host's groups, if we're not in anyone, let's not
# add the current user to any sudoers group, so that host's sudo settings are
# respected

What seems to be confusing - when container becomes rootful. I have a feeling that with podman containers are rootless by default (because container runs with user privileges) and with docker containers are rootful by default (because containers run by dockerd which runs as root). But I may be wrong and those who care are welcome to make their own research. I satisfied my curiosity here :slight_smile:

I tried creating a new container and it’s been stuck “Starting container…” for 15 minutes.

docker logs -f ROCm