> distrobox list
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.45/containers/json?all=1": dial unix /var/run/docker.sock: connect: permission denied


Docker socket in openSUSE has a following permissions

$ stat /run/docker.sock 
  File: /run/docker.sock
  Size: 0         	Blocks: 0          IO Block: 4096   socket
Device: 0,26	Inode: 1914        Links: 1
Access: (0666/srw-rw-rw-)  Uid: (    0/    root)   Gid: (  471/  docker)

So it can be accessed by users in a docker group. You can check the list of a groups via id command or userctl user $login.

So the point is that there is no mention (the one similar to VirtualBox) about the current user  is supposed to be part of the Docker group which could easily be set in %post / %posttrans script as: `usermod -aG $USER docker` (or equivalent...).


I shall give it a try again later and change the status quota of the issue here . .  


Thanks for the reply.

There is official documentation that describes manual steps post-install on Linux, see https://docs.docker.com/engine/install/linux-postinstall/.

I don't classify this as a bug, but rather well-known behavior. Changes to the Docker package would be a feature request.

Aleksa, should we add users to groups in %post/%posttrans scripts?

(In reply to Alexandre Vicenzi from comment #3)
> There is official documentation that describes manual steps post-install on
> Linux, see https://docs.docker.com/engine/install/linux-postinstall/.
> 
> I don't classify this as a bug, but rather well-known behavior. Changes to
> the Docker package would be a feature request.
> 
> Aleksa, should we add users to groups in %post/%posttrans scripts?



Nope, it is not a BUG indeed.
It is rather my oversight than anything else.

But it is a formerly missing information by those who maintain it - As a post installation step / notification about what needs to be done in order to use the software.

(In reply to Alexandre Vicenzi from comment #3)
> There is official documentation that describes manual steps post-install on
> Linux, see https://docs.docker.com/engine/install/linux-postinstall/.
> 
> I don't classify this as a bug, but rather well-known behavior. Changes to
> the Docker package would be a feature request.
> 
> Aleksa, should we add users to groups in %post/%posttrans scripts?

Access to the docker group gives you admin privileges to the machine (it is trivial to get root host access using Docker) and so automatically adding users seems like a bad idea in general. We also don't know which users we should add to the group at install time anyway.

(In reply to Martin von Reichenberg from comment #2)
> So the point is that there is no mention (the one similar to VirtualBox)
> about the current user  is supposed to be part of the Docker group which
> could easily be set in %post / %posttrans script as: `usermod -aG $USER
> docker` (or equivalent...).

(In reply to Martin von Reichenberg from comment #4)
> But it is a formerly missing information by those who maintain it - As a
> post installation step / notification about what needs to be done in order
> to use the software.

I don't see anything in the VirtualBox spec file which would tell users about the vboxusers group at install time. If you want, we can add a line in the package documentation about the docker group, but the fact that you need to be part of the docker group to administer Docker is incredibly common knowledge for users of Docker. As mentioned above, this is mentioned already by the upstream documentation.

(In reply to Aleksa Sarai from comment #5)
> (In reply to Alexandre Vicenzi from comment #3)
> > There is official documentation that describes manual steps post-install on
> > Linux, see https://docs.docker.com/engine/install/linux-postinstall/.
> > 
> > I don't classify this as a bug, but rather well-known behavior. Changes to
> > the Docker package would be a feature request.
> > 
> > Aleksa, should we add users to groups in %post/%posttrans scripts?
> 
> Access to the docker group gives you admin privileges to the machine (it is
> trivial to get root host access using Docker) and so automatically adding
> users seems like a bad idea in general. We also don't know which users we
> should add to the group at install time anyway.
> 
> (In reply to Martin von Reichenberg from comment #2)
> > So the point is that there is no mention (the one similar to VirtualBox)
> > about the current user  is supposed to be part of the Docker group which
> > could easily be set in %post / %posttrans script as: `usermod -aG $USER
> > docker` (or equivalent...).
> 
> (In reply to Martin von Reichenberg from comment #4)
> > But it is a formerly missing information by those who maintain it - As a
> > post installation step / notification about what needs to be done in order
> > to use the software.
> 
> I don't see anything in the VirtualBox spec file which would tell users
> about the vboxusers group at install time. If you want, we can add a line in
> the package documentation about the docker group, but the fact that you need
> to be part of the docker group to administer Docker is incredibly common
> knowledge for users of Docker. As mentioned above, this is mentioned already
> by the upstream documentation.


VirtualBox shows the notification window at the initial runtime.

In case of DistroBox it is not clear at the very first usage that it's all bound to Docker (- services/groups). 

Probably an echo/printf message could be enough, but it should be told after install or initial startup somehow - more likely a request to upstream.

> In case of DistroBox it is not clear at the very first usage that it's all bound to Docker (- services/groups). 

Distrobox already states in its documentation that it requires rootless podman/docker to work properly and also links to proper instructions.

See: https://distrobox.it/compatibility/#supported-container-managers

> Probably an echo/printf message could be enough, but it should be told after install or initial startup somehow - more likely a request to upstream.

For now, I'm going to close this as there's nothing we can do on our side.

Issues raised upstream with permission denied are often closed as invalid and pointed to the documentation. If there's a reliable way to detect that the system is not in rootless mode, it might be worth implementing it upstream and printing it out to warn the user.