Unable to start or create instances due to Docker error code 125. (v2.6)

Technical Support
,
1

OS Name/Version: Windows 11 Pro 24H2

Product Name/Version: 2.6.1.6

Problem Description:

Whenever I attempt to start an existing docker instance (click “Start Instance” button on offline instance) or create a new docker instance (click “Create Instance” button) I encounter the error:

Startup failure: Docker returned error code 125

The instances I’m using are created before the error started happening.

The Deployment Log (debug level) contains the following error messages:

Running command line: "C:\Program Files\Docker\Docker\resources\bin\docker.exe ps --format {{.Names}}" from ""
Running command line: "C:\Program Files\Docker\Docker\resources\bin\docker.exe pull cubecoders/ampbase" from ""
Using default tag: latest
error during connect: in the default daemon configuration on Windows, the docker client must be run with elevated privileges to connect: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.49/images/create?fromImage=docker.io%2Fcubecoders%2Fampbase&tag=latest": open //./pipe/docker_engine: Access is denied.
Running command line: "C:\Program Files\Docker\Docker\resources\bin\docker.exe run --rm -d --name AMP_Avorion01 -v "K:\AMP\DataStore\Avorion01":/AMP -v "K:\AMP\DataStore\Avorion01\.virtualhome":/home/amp -e AMPUSERID=1001 -e AMPGROUPID=1001 -e AMPHOSTPLATFORM=Windows -e AMP_CONTAINER=1 -e AMP_MOUNTPOINTS="" --mac-address XX:XX:XX:XX:XX:XX -p 8084:8084/tcp -p 2227:2227/tcp -p 27015:27015/tcp -p 27015:27015/udp -p 27017:27017/udp -p 27020:27020/udp -p 27021:27021/udp -p 27018:27018/tcp cubecoders/ampbase +Core.Webserver.Port \"8084\" +Core.Webserver.IPBinding \"0.0.0.0\" +Core.AMP.InstanceID \"5d31106a-XXXX-XXXX-XXXX-f4d985152d78\" +Core.Security.MetricsHMAKKey \"030cf63a-XXXX-XXXX-XXXX-1ca8269a024e\"" from ""
docker: error during connect: in the default daemon configuration on Windows, the docker client must be run with elevated privileges to connect: Head "http://%2F%2F.%2Fpipe%2Fdocker_engine/_ping": open //./pipe/docker_engine: Access is denied.
Run 'docker run --help' for more information

Based on other similar reports, I’ve followed the instructions to setup Docker.

Other things I’ve done:

  • Verified that NETWORK SERVICE is a member of the docker-users group.
  • Verified all AMP.exe and AMPService.exe is running under the NETWORK SERVICE user.
  • Updated AMP to 2.6 from 2.4.
  • Ensured all Docker Desktop updates have been installed.
  • Rebooted the machine several times.
  • Created instance without using docker.
2

Since that was a decently large version jump to make while updating, double check that ampinstmgr version in CMD prints out the expected AMP version. If it doesn’t read the new version, follow this guide here and be sure to follow the section regarding updating your CLI tools.
https://discourse.cubecoders.com/t/how-to-update-amp-to-the-latest-version/2297

If that all checks out, some people having issues with Docker on Windows had to downgrade their Docker Desktop version to 4.39, so that may be something to double check.
(With the older installer you’d have to run .\Docker_Installer.exe install --disable-version-check)

3

Yup, it looks like the command line tools have been properly upgraded:

C:\Program Files\CubeCoders Limited\AMP>ampinstmgr.exe version
[Info/1] AMP Instance Manager v2.6.1.6 built 21/04/2025 13:40
[Info/1] Stream: Mainline / Release - built by CUBECODERS/buildbot on CCL-DEV

I did get a warning that the command line tools where out-of-date so I followed the instructions that it pointed me off to.

I’ll try downgrading Docker. It ties in with something I discovered earlier today.

I discovered an issue on Docker’s tracker with some commands that helped me discover some more details on what was going on:

PS C:\Users\user> [System.IO.Directory]::GetAccessControl("\\.\pipe\docker_engine") | Format-Table -Wrap

Path Owner         Access
---- -----         ------
     COMPUTER\user NT AUTHORITY\SYSTEM Allow  FullControl
                   BUILTIN\Administrators Allow  FullControl
                   COMPUTER\user Allow  Write, Read, Synchronize


PS C:\Users\user> net localgroup docker-users
Alias name     docker-users
Comment        Members of this group can access features exposed by the Docker Desktop service (such as Windows Containers and the Hyper-V backend).

Members

-------------------------------------------------------------------------------
user
NT AUTHORITY\NETWORK SERVICE
The command completed successfully.

Apparently under docker 4.41.2 (191736), the docker engine control pipe doesn’t grant permissions to the docker-users group. I do have docker installed under a user account, and I have to manually login to the user account to get docker desktop started. I use the free/personal license while signed out, so I don’t know if it behaves differently under a paid/business license.

Later on in the same issue tracker, someone replied with a link off to another repo that has a power shell script that patches permissions to the docker engine control pipe.

I tried following the list of manual commands the repo contained while using an administrator account and was able to patch the permissions on the pipe to grant the Network Services user permission to the pipe.

PS C:\Users\admin> $account = "NT AUTHORITY\NETWORK SERVICE"
PS C:\Users\admin> $npipe = "\\.\pipe\docker_engine"
PS C:\Users\admin> $dInfo = New-Object "System.IO.DirectoryInfo" -ArgumentList $npipe
PS C:\Users\admin> $dSec = $dInfo.GetAccessControl()
PS C:\Users\admin> $fullControl = [System.Security.AccessControl.FileSystemRights]::FullControl
PS C:\Users\admin> $allow = [System.Security.AccessControl.AccessControlType]::Allow
PS C:\Users\admin> $rule = New-Object "System.Security.AccessControl.FileSystemAccessRule" -ArgumentList $account,$fullControl,$allow
PS C:\Users\admin> $dSec.AddAccessRule($rule)
PS C:\Users\admin> $dInfo.SetAccessControl($dSec)
PS C:\Users\admin> [System.IO.Directory]::GetAccessControl("\\.\pipe\docker_engine") | Format-Table -Wrap

Path Owner         Access
---- -----         ------
     COMPUTER\user NT AUTHORITY\SYSTEM Allow  FullControl
                   NT AUTHORITY\NETWORK SERVICE Allow  FullControl
                   BUILTIN\Administrators Allow  FullControl
                   COMPUTER\user Allow  Write, Read, Synchronize

It did work and AMP was able to operate docker containers as normal. The patch is temporary and doesn’t survive reboots, unfortunate but expected. I was going to try looking to see if there was a way I could set up automatic patching of the pipe’s acl, but downgrading docker seems like a way easier solution if it works.

Update: I downgraded to Docker Desktop 4.39 and the pipe’s acl grants permission to the docker-users group. AMP works as expected.

PS C:\Users\user> [System.IO.Directory]::GetAccessControl("\\.\pipe\docker_engine") | Format-Table -Wrap

Path Owner         Access
---- -----         ------
     COMPUTER\user NT AUTHORITY\SYSTEM Allow  FullControl
                   BUILTIN\Administrators Allow  FullControl
                   COMPUTER\docker-users Allow  Write, Read, Synchronize
4

Oh that’s some nifty info you found there! I’ll pass that along to Mike and Ice in case they’re unaware of that.

5

I wonder if this is in fact a bug in Docker Engine, otherwise how would non admin users be able to use Docker? The documentation still says that you just need to add a user to the group as normal.

6

It does seem like it could be a bug in Docker Engine. I’ve confirmed it changed between 4.39 and 4.40, but nothing in the changelists between versions between 4.39 and 4.40 of Docker Desktop (or 28.0.1 to 28.0.4 of Docker Engine) seemed to suggest they intentionally made changes to the pipe’s ACL.

As for non-admin users, based on the ACL, it appears only the user that launches Docker Desktop is allowed access to the docker engine pipe. The default ACL includes the user account I’m using (COMPUTER\user in the output above), but since it doesn’t grant docker-users permission, only Administrators can otherwise interact with the pipe.

Since I don’t rely on Docker outside of AMP, downgrading and staying on 4.39 is sufficient for my limited use case.

7

I believe this is the same issue we discussed a couple weeks ago in Discord.

I do think this regression might be intentional in docker due to security vulnerabilities.

Perhaps someone can post an issue here?