freedomofpress
Certain Podman flags make conversions fail on Windows
While testing Podman Desktop support (see #925) on Windows platforms, we found out that the following flags that Dangerzone passes may fail document conversions:
--userns nomap
This flag works only if Podman has been set in rootless mode. Here's how you can do this on Windows:
https://github.com/containers/podman/blob/main/docs/tutorials/podman-for-windows.md#rootful--rootless
From personal experience, it seems that users who set up the Podman Desktop machine via CLI end up with a rootless Podman installation, by default. However, users who set up Podman Desktop machinge via the GUI end up with a rootful Podman installation, by default.
In the latter case, conversions fail with message Unknown error code '125'. The underlying Podman error though is Error: nomap is only supported in rootless mode.
CLI output:
[INFO ] > 'C:\Program Files\RedHat\Podman\podman.EXE' run --log-driver none --security-opt no-new-privileges --userns nomap --cap-drop all --cap-add SYS_CHROOT --security-opt label=type:container_engine_t --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-Ox6ydU dangerzone.rocks/dangerzone:20250331-0.9.0-rc1-13-g067c741-a2ec /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
[INFO ] Conversion output (doc to pixels)
----- DOC TO PIXELS LOG START -----
Error: nomap is only supported in rootless mode
----- DOC TO PIXELS LOG END -----
[ERROR] [doc Ox6ydU] 0% Unknown error code '125'
[DEBUG] Marking doc Ox6ydU as 'failed'
Failed to convert document(s)
C:\Users\dz\dangerzone\tests\test_docs\sample-pdf.pdf
--security-opt seccomp=C:/Program Files/Dangerzone/share/seccomp.gvisor.json
Dangerzone passes a platform-agnostic flag to the underlying container runtime that makes it use a particular seccomp policy. For Podman Desktop in Windows though, passing this flag makes conversions fail with message Unknown error code '125'. The underlying Podman error though is Error: opening seccomp profile failed: open C:\Users\dz\dangerzone\share\seccomp.gvisor.json: no such file or directory. Interestingly, this file exists locally, so this looks like an issue we need to open upstream.
CLI output:
[INFO ] > 'C:\Program Files\RedHat\Podman\podman.EXE' run --log-driver none --security-opt no-new-privileges --userns nomap --security-opt 'seccomp=C:\Users\dz\dangerzone\share\seccomp.gvisor.json' --cap-drop all --cap-add SYS_CHROOT --security-opt label=type:container_engine_t --network=none -u dangerzone --rm -i --name dangerzone-doc-to-pixels-K9qaxF dangerzone.rocks/dangerzone:20250331-0.9.0-rc1-13-g067c741-a2ec /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
[INFO ] Conversion output (doc to pixels)
----- DOC TO PIXELS LOG START -----
Error: opening seccomp profile failed: open C:\Users\dz\dangerzone\share\seccomp.gvisor.json: no such file or directory
----- DOC TO PIXELS LOG END -----
[ERROR] [doc K9qaxF] 0% Unknown error code '125'
[DEBUG] Marking doc K9qaxF as 'failed'
Failed to convert document(s)
C:\Users\dz\dangerzone\tests\test_docs\sample-pdf.pdf
Thanks for opening this, interesting to know what's missing to have Dangerzone run on Podman Desktop for Windows! (experimental support is…experimental!)
The fact that the conversion continues to error with this Unknown error code '125' seem problematic to me, and we might want to have better error handling around for this, especially not swallowing the error themselves.
I agree. I think that to properly close this issue we need to:
- Have a proper error message for this bug (or create a more general issue for this lack of UX from our side)
- Inform the Podman team about the seccomp failure
- (optional) Detect if Podman runs in rootless mode, and therefore enable
--userns nomap
For the time being, I have opened a PR that refs this issue, and has some workarounds: #1129
I'm having what might be a similar issue with podman desktop on macos Intel silicon. Every conversion in Dangerzone fails with "unknown error 125"
It's not clear how I can see the debug output above to see if it's caused by the same issue or not.
Strangely, the issue ONLY seems to occur when the podman-machine-default is started within Podman desktop app. When I start it from the CLI via podman machine start, Dangerzone works fine.
I thought maybe I'd see a difference in how the container was started but I compared the process listings for "podman" from desktop and CLI and they only differ by PID and time and tty.
501 32337 1 0 11:03AM ttys000 0:00.05 /opt/homebrew/Cellar/podman/5.5.2/libexec/podman/gvproxy -mtu 1500 -ssh-port 55357 -listen-vfkit unixgram:///var/folders/7d/jkbmd5t91q91kt_q2lqqd2k80000gn/T/podman/podman-machine-default-gvproxy.sock -forward-dest /run/user/501/podman/podman.sock -forward-user core -forward-identity /Users/jaxley/.local/share/containers/podman/machine/machine -forward-sock /var/folders/7d/jkbmd5t91q91kt_q2lqqd2k80000gn/T/podman/podman-machine-default-api.sock -pid-file /var/folders/7d/jkbmd5t91q91kt_q2lqqd2k80000gn/T/podman/gvproxy.pid -log-file /var/folders/7d/jkbmd5t91q91kt_q2lqqd2k80000gn/T/podman/gvproxy.log
501 32338 1 0 11:03AM ttys000 0:00.04 /opt/homebrew/Cellar/podman/5.5.2/libexec/podman/vfkit --cpus 4 --memory 2048 --bootloader efi,variable-store=/Users/jaxley/.local/share/containers/podman/machine/applehv/efi-bl-podman-machine-default,create --device virtio-blk,path=/Users/jaxley/.local/share/containers/podman/machine/applehv/podman-machine-default-arm64.raw --device virtio-rng --device virtio-vsock,port=1025,socketURL=/var/folders/7d/jkbmd5t91q91kt_q2lqqd2k80000gn/T/podman/podman-machine-default.sock,listen --device virtio-serial,logFilePath=/var/folders/7d/jkbmd5t91q91kt_q2lqqd2k80000gn/T/podman/podman-machine-default.log --device rosetta,mountTag=rosetta,install --device virtio-net,unixSocketPath=/var/folders/7d/jkbmd5t91q91kt_q2lqqd2k80000gn/T/podman/podman-machine-default-gvproxy.sock,mac=5a:94:ef:e4:0c:ee --device virtio-fs,sharedDir=/Users,mountTag=a2a0ee2c717462feb1de2f5afd59de5fd2d8 --device virtio-fs,sharedDir=/private,mountTag=71708eb255bc230cd7c91dd26f7667a7b938 --device virtio-fs,sharedDir=/var/folders,mountTag=a0bb3a2c8b0b02ba5958b0576f0d6530e104 --device virtio-fs,sharedDir=/Applications/Dangerzone.app,mountTag=c768e727aefa7fe57f4c78d49d61dfd78820 --restful-uri tcp://localhost:55366
Thanks @jaxley for letting us know. I've opened another issue in #1187 to discuss (and hopefully solve!) this.
Regarding the seccomp path issue, where Podman does not seem to find it even though it exists, I've opened an issue upstream: https://github.com/containers/podman/issues/26558
A workaround for now is to do the path translation ourselves. That is, change backslashes to forward slashes, and replace C:/ with /mnt/c:
subpath = seccomp_json_path.relative_to("C:\\").as_posix()
seccomp_json_path = PurePosixPath("/mnt/c") / subpath