Unknown server OS error on Ubuntu 24.04.3 LTS #6694

Activity

1. locnnil

   added

   kind/bug

   status/0-triage

   on Dec 5, 2025
2. thaJeztah commented on Dec 5, 2025

   

   thaJeztah

   on Dec 5, 2025

   Member

   More actions

   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)
   	}
3. thaJeztah

   added

   version/29.1

   on Dec 5, 2025
4. locnnil commented on Dec 5, 2025

   

   locnnil

   on Dec 5, 2025

   Last edited by locnnil

   Author

   More actions

   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.
5. thaJeztah commented on Dec 5, 2025

   

   thaJeztah

   on Dec 5, 2025

   Member

   More actions

   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.

   👀React with 👀1Reacted by Lincoln Wallace
6. thaJeztah commented on Dec 11, 2025

   

   thaJeztah

   on Dec 11, 2025

   Member

   More actions

   I opened a PR to (at least as intermediate step) return the connection error instead of swallowing it; that should fix the immediate issue (and make it more clear that the command failed because the CLI was unable to connect with the daemon)

   • docker run, create: don't swallow connection errors during validate #6700

   🎉React with 🎉1Reacted by Lincoln Wallace
7. thaJeztah

   closed this as completedin #6700on Dec 11, 2025