Share and learn in the Docker community.
Hello,
How may I be allowed to use vsocks within an unprivileged container ?
docker run -ti --privileged=false --device=/dev/vsock alpine ash
/ # ls -l /dev/vsock
crw-rw-rw- 1 root root 10, 122 Jan 26 20:42 /dev/vsock
/ # apk update ; apk add socat
/ # socat VSOCK-CONNECT:2:1234 -
2025/01/26 20:44:01 socat[12] E socket(40, 1, 0): Operation not permitted
/ #
(with ‘socat VSOCK-LISTEN:1234 -’ in the host)
Is there any capabilities to request or similar?
Regards
Since it is network-related, you can try NET_ADMIN.
Unfortunately, I always get the same error “Operation not permitted”
As a general rule, vsock can be used by simple users. What’s wrong here?
Regards
You could start sharing more context with stating your OS and output of docker info.
Hello,
I run a debian trixie:
$ uname -a
Linux my_pc 6.12.10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.10-1 (2025-01-18) x86_64 GNU/Linux
$ docker info
Client: Docker Engine - Community
Version: 27.5.1
Context: default
Debug Mode: false
Plugins:
ai: Ask Gordon - Docker Agent (Docker Inc.)
Version: v0.5.1
Path: /usr/lib/docker/cli-plugins/docker-ai
buildx: Docker Buildx (Docker Inc.)
Version: v0.19.2-desktop.1
Path: /usr/lib/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.31.0-desktop.2
Path: /usr/lib/docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.37
Path: /usr/lib/docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Beta) (Docker Inc.)
Version: v0.1.0
Path: /usr/lib/docker/cli-plugins/docker-desktop
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: /usr/lib/docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.27
Path: /usr/lib/docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: /usr/lib/docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.4.0
Path: /usr/lib/docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /usr/lib/docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.15.1
Path: /usr/lib/docker/cli-plugins/docker-scout
Server:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 3
Server Version: 27.5.1
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan kathara/katharanp_vde:amd64 macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
runc version: v1.2.4-0-g6c52b3f
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.12.10-amd64
Operating System: Debian GNU/Linux trixie/sid
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 31.23GiB
Name: dyn-salsa-030
ID: 287b6e2a-9feb-43c7-b772-dfd26a71b4e3
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Regards
It seems Trixie is not released yet (doc).
Furthermore, it looks like the client, uses the cli and plugins provided by docker desktop, while the server seems to use docker-ce. Isn’t a vsock similar to a unix domain socket, some sort of ipc channel? WIth the docker.sock, which is a unix domain socket, binding the socket as volume is enough to use it inside a container. Is it maybe the same with a vsock? Of course this can only work with docker-ce, as Docker Desktop runs its backend in a utility vm, which won’t be able to access the vsock.
Hello,
@bluepuma77: I just did a test on a newly installed Noble Ubuntu, just to be sure.
Unsurprisingly, the result is the same as for Trixie: vsock works in privileged mode, not unprivileged mode.
@meyay: You have good eyes: on my Trixie pc, a Docker Desktop package is installed.
It wasn’t active during testing, but it was present.
Note that on my Noble install, it was not present.
But you raise an interesting point.
So I made test with Docker Desktop: vsock doesn’t work at all!
Not even in privileged mode (except for loopback connections, which aren’t very interesting).
The additional VM layer of Docker Desktop does not seem to provide a forwarding service for vsock.
This is unfortunate, because that’s precisely what vsock is designed to do: communicate between containers and the host.
Well, may I suggest a feature request: make Docker more vsock-friendly 
I guess such a feature request would need to be done the Docker Desktop for Linux Github Repo:
There is an issue in the moby repo (for Docker CE, while the one shared by @meyay is for Docker Desktop)
So you can try
docker run -ti --privileged=false --device=/dev/vsock --security-opt seccomp=unconfined alpine ash
or simply
docker run -ti --device=/dev/vsock --security-opt seccomp=unconfined alpine ash
But if I understand it correctly, it is not enough
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.