tfenster/dockeraccesshelper

Persist across reboots

Opened this issue · 10 comments

Hi,

Thanks for the great bit of code, it's making my DevOps build agents more useful.

There does seem to be an issue with the fix however - the permission is not persisting across reboots. Whenever one of the servers is rebooted, the DevOps agents fail to connect and I have to re-execute the PS1 script.

Is there any way of either changing the code to persist or, is this something that would be best performed in Windows Startup or something? (Assuming the script can be run as an administrator).

Cheers

@andyofengland A better solution for that would be to configure a group in the standard daemon config as described here https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#set-docker-security-group. Does that work for you?

Hi,
That does sound like a good approach - perhaps it's something to add into the script as an option?
Cheers

@andyofengland not sure if I understand you: Do you mean to create that entry in to config file?

@andyofengland A better solution for that would be to configure a group in the standard daemon config as described here https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#set-docker-security-group. Does that work for you?

It did not work for me :-(

What I did
New-LocalGroup -Name 'docker-users' -Description 'docker Users Group'
Add-LocalGroupMember -Group 'Administrators' -Member ('docker-users') –Verbose
Add-LocalGroupMember -Group 'docker-users' -Member ('XXX\XXXX','Administrators') –Verbose

& Then configure daemon.json {"group":"docker-users"} & restart service.

No change still needs to run the add-on manually. Am I doing something wrong here?

looks good to me. If that doesn't work, I would say it's a bug in docker itself, so you would need to open an issue there

Hey! Thanks for this thread. I had the same issue as well with pipe access resetting after server reboot.
Here's what I did:

Powershell:

New-LocalGroup -Name 'docker-users' -Description 'docker Users Group'
Add-LocalGroupMember -Group 'docker-users' -Member ('xx\xxx$','Administrators') –Verbose

where xx\xxx$ was the user (GMSA user in this case) that runs the build agent

I then edited the daemon.json and andded "group" : "docker-users"

At first I thought that the method does not work because Restart-Service "Docker Engine" did not solve the rights issue. But after rebooting the server again, all was working. So the key part is restarting the server afterwards.

Hi!
Where should this 'daemon.json' file be located?

I am facing the same issue with Docker Engine on Windows (10/11). I came across this script, which finally solves my problem...
...til the system is rebooted.
I have a 'docker-user' group, so I guess the last thing is to add this entry in the daemon.json file. But where is it?

Again, this is Docker Engine on windows, so no installation. Following this: https://docs.docker.com/engine/install/binaries/

To configure the Docker daemon using a JSON file, create a file at
/etc/docker/daemon.json on Linux systems, or
C:\ProgramData\docker\config\daemon.json on Windows.
On MacOS go to the whale in the taskbar > Preferences > Daemon > Advanced.

@andyofengland not sure if I understand you: Do you mean to create that entry in to config file?

I suggest to instead mention the alternative approach (setting the group in daemon.json) in the README.md and to refer to the Docker documentation (https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#set-docker-security-group).

When I was looking for a solution to run Docker without admin rights, I only found this repository here (and the corresponding blog entry: https://www.axians-infoma.com/techblog/allow-access-to-the-docker-engine-without-admin-rights-on-windows/). So I thought, this was the only solution. But using a user group seems much more convenient, at least for me.