Unknown server OS error on Ubuntu 24.04.3 LTS

[locnnil]

Description

This happens only when the user isn't on the docker group and the user run the command without using sudo.

Docker run command exits with: Docker command exits with unknown server OS:

Reproduce

1. Install docker
2. docker run --device=/dev/dri -it intel/oneapi-basekit

Expected behavior

Docker error out with non-allowed unix socket permissions like:

docker: permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

docker version

$ sudo docker version
Client: Docker Engine - Community
 Version:           29.1.2
 API version:       1.52
 Go version:        go1.25.5
 Git commit:        890dcca
 Built:             Tue Dec  2 21:55:19 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.1.2
  API version:      1.52 (minimum version 1.44)
  Go version:       go1.25.5
  Git commit:       de45c2a
  Built:            Tue Dec  2 21:55:19 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.0
  GitCommit:        1c4457e00facac03ce1d75f7b6777a7a851e5c41
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

$ sudo docker info
Client: Docker Engine - Community
 Version:    29.1.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.30.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 29.1.2
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1c4457e00facac03ce1d75f7b6777a7a851e5c41
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-88-generic
 Operating System: Ubuntu 24.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 11.67GiB
 Name: nr
 ID: 0f3d92ed-0eac-4bd2-abf5-c5a53fce210b
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Additional Info

Originally reported here:

• Unknown server OS canonical/docker-snap#336

[thaJeztah]

Thanks for reporting; this error happens as part of a validation step, which connects to the daemon to determine if it's a linux or windows daemon. I see your other commands fail without sudo because the user doesn't have permissions to access the docker API socket; Does it work if you run the command with sudo ?

Some of the validation could / should be relaxed, and probably not be performed on the client-side, but from the above, I wonder if it's a permission issue;

cli/cli/command/container/opts.go

Lines 995 to 1003 in 1a1a4fc

	func parseDevice(device, serverOS string) (container.DeviceMapping, error) {
	switch serverOS {
	case "linux":
	return parseLinuxDevice(device)
	case "windows":
	return parseWindowsDevice(device)
	}
	return container.DeviceMapping{}, fmt.Errorf("unknown server OS: %s", serverOS)
	}

[locnnil]

Does it work if you run the command with sudo ?

Yes! It does work, in the same way, if the user is part of the docker group as well.

I wonder if it's a permission issue;

My guess is that something is going wrong earlier in the path related to the parsing of --device=/dev/dri, that causes serverOS to be an empty string.

[thaJeztah]

My guess is that something is going wrong earlier in the path related to the parsing of --device=/dev/dri, that causes serverOS to be an empty string.

Yes, that's exactly what happens; this line gets the ServerInfo, and takes the OS from it;

cli/cli/command/container/create.go

Line 115 in 1a1a4fc

containerCfg, err := parse(flags, copts, dockerCli.ServerInfo().OSType)

However, that info is generally used as "informative" and assumed to not interrupt the regular flow if it fails (any failure to connect would normally surface either way when making the actual API request). However, the validation doesn't match that; it's currently written to be a hard failure, not a warning.

The validation for devices has been on my radar for some time; as I mentioned above, it shouldn't really be the CLI / client's responsibility to validate those, simply because it won't have all the information needed to fully validate if the given values are correct, so at best it could look if the paths are in an acceptable format, but even that already depends on whether the daemon is Windows or Linux, so we should probably remove that validation altogether.

There's some other (similar) validations I stumbled upon, but in some cases I found that the client-side validation was the only validation happening; the daemon (API) would still fail, but with an obscure error, so some improvements had to be made on the daemon side before removing the client-side validation.