Linux: Rootless docker only starting after user login

Hi,

I have been using docker now for a while and am very happy with it.

I discovered rootless docker and am trying to use it as often as possible for security reasons. But I just realized that - for some reason - docker rootless does not seem to start until the user logs in (despite enabling it as a service).

Is that expected or am I doing something wrong?

Thanks!

The rootless docker is a docker daemon running as the user who uses it and it requires the user-level systemd process to start which will not start until the user logs in.

If I remember correctly, someone on this forum managed to run a systemd service that started a user-level systemd, but the documentation mentions another solution

https://docs.docker.com/engine/security/rootless/#daemon

To launch the daemon on system startup, enable the systemd service and lingering:

$ systemctl --user enable docker
$ sudo loginctl enable-linger $(whoami)
1 Like

Thank you.

Rootless docker is enabled and allowed to linger as per the docs but it still doesn’t start until the user logs in.

So just for my understanding: If rootless docker is enabled and allowed to linger as per the docs, should it then automatically start at boot (same as rootful docker) or is it expected to only run once the user logs in?

I tried it in a virtual machine. It worked with Docker CE 26.1.0. The method is also shown when you run

dockerd-rootless-setuptool install --force

But it is important to run the command exactly as it is shown so the whoami command runs as your user, but loginctl runs as root. If you switch to root user and run the command as root, whoami will return root, not your username. If your non-root user has no sudo privileges, just replace $(whoami) with your actual username. I used “test” so I had to run this as root:

loginctl enable-linger test
1 Like

So I take it, if installed as per the docs, also rootless docker should start without a user logging in, right?

Well, I think I did install it as per the docs.

But you mention now that if the user has sudo privileges, one should not use $(whoami). Well, my user does have sudo privileges but I did not replace $(whoami) with the user name.

So maybe that’s the root of the problem - so to speak.

Can I simply run loginctl enable-linger and “over-write” the current setting?

No. I was saying run the commands exactly as they are written, but run them as your user, not as root. IF you run the commands as root, only then you have a problem as the whoami command will return root and you definitely don’t want to execute loginctl enable-linger root. You want to execute loginctl enable-linger YOURUSERNAME where YOURUSERNAME must be replaced by your actual username. If your user has sudo privileges, and you don’t switch to the root user before running the commands in the documentation, that should work. And it worked for me. If you share the eexact commands you ran including the prompt which probably contains the username, maybe we can tell what you do wrong.

Sorry, I don’t understand what you mean. What do you want to overwrite?

You’re right. I expressed myself wrongly:

I understand that because I ran the commands as per the docs (and because my user has sudo privileges), it is not working as intended. If the user didn’t have sudo privileges, it would have worked. But the way things are, it didn’t.

Now I need to rectify things.

What I wrote before was: Can I simply run loginctl enable-linger username (I had put “username” in pointy brackets < > and then, for some reason, it was removed from my post and so it only reads loginctl enable-linger – which doesn’t make sense; I agree).

I did write the commands exactly as per the docs. BUT my user had sudo privileges. So this is where things took the wrong turn.

I now want to overwrite loginctl enable-linger root with loginctl enable-linger username – would that work?

It is not overriding. You can enable lingering to any user. Root is always there anyway. Just run the command with the right user and you are done. If you want to disable it for a user, then you need disable-linger not enable-linger.

And again, in case of it still wasn’t clear, forget about sudo. You obviously need sudo if you follow the documentation.

Okay, I think this time I got it. Or maybe I don’t – we’ll see.

At least, my rootless docker in a test vm actually started after boot before I logged in as the respective user. Thank you very much for your help and your patience.

So to summarize:

In order to get rootless docker to start on its own, per the official documentation one has to execute

$ systemctl --user enable docker
$ sudo loginctl enable-linger $(whoami)

But if one does that, it doesn’t work because due to sudo $(whoami) is resolved to “root” and so lingering is enabled for the wrong user.

On the other hand, without sudo enable-linger doesn’t work for an ordinary user. So lingering isn’t enabled at all.

And the right way to do it is to execute

sudo loginctl enable-linger <username>

Then my last question would be: Why doesn’t it say so in the documentation?

I’m not sure I understand your description. I couldn’t explain it better than I did, so I just try to give you some Linux tips.

The command sudo $(whoami) is not resolved to anything. whoami gives you the current user. If you run it as root, then it gives you root, but you don’t have to be root to be able to use the sudo command. The sudo command can execute a command as a super user (su), but the $( ANY COMMAND ) syntax opens a “subshell” so it runs before sudo at the beginning of the command.

I’m still not sure what you miss from the documentation, but I hope my answer will be the answer to your question. The documentation includes what you need to know about Docker. It requires basic Linux knowledge and it can’t explain everything unfortunately. Docker tries to be easy to use, but it is still an advanced tool and we always need to understand the operating system as well. When we run Docker Desktop, it becomes even more complicated, because then we need to understand the operating system in the container and the operating system on the host (if not the same)

I hope my answer makes sense. If you think the documentation needs to be more precise or clearer, you can request a change (top right corner on each docs page)