freedomofpress
GUI fails with "Unknown error code '0'"
Converting certain documents with Docker Desktop 4.39 results in an error 'Unknown error code '0'.
[!NOTE] Docker Desktop 4.39 is known to fail with Dangerzone, and a fix is yet to be released by upstream. In the meantime, you can use Docker Desktop 4.38. If you are hitting this bug on Linux, please upgrade Docker-cli to v
28.0.4.
Details
What happened?
Attempting to convert a .docx or .ppt file results in "Unknown error code '0'" displayed in the GUI. Attempting to convert the same file via dangerzone-cli works.
Running the GUI on the terminal, it shows an Error: No such option: -B, which dangerzone-cli does not.
operating system version
macOS 15.2
Processor type
Apple Silicon M1
Dangerzone version
0.8.1
Docker info
% docker version
Client:
Version: 28.0.1
API version: 1.48
Go version: go1.23.6
Git commit: 068a01e
Built: Wed Feb 26 10:38:16 2025
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.39.0 (184744)
Engine:
Version: 28.0.1
API version: 1.48 (minimum version 1.24)
Go version: go1.23.6
Git commit: bbd0a17
Built: Wed Feb 26 10:40:57 2025
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.7.25
GitCommit: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
runc:
Version: 1.2.4
GitCommit: v1.2.4-0-g6c52b3f
docker-init:
Version: 0.19.0
GitCommit: de40ad0
% docker info -f 'json'
{"ID":"d9c85432-ef4c-439c-90dc-6edc6be5b405","Containers":0,"ContainersRunning":0,"ContainersPaused":0,"ContainersStopped":0,"Images":1,"Driver":"overlay2","DriverStatus":[["Backing Filesystem","extfs"],["Supports d_type","true"],["Using metacopy","false"],["Native Overlay Diff","true"],["userxattr","false"]],"Plugins":{"Volume":["local"],"Network":["bridge","host","ipvlan","macvlan","null","overlay"],"Authorization":null,"Log":["awslogs","fluentd","gcplogs","gelf","journald","json-file","local","splunk","syslog"]},"MemoryLimit":true,"SwapLimit":true,"CpuCfsPeriod":true,"CpuCfsQuota":true,"CPUShares":true,"CPUSet":true,"PidsLimit":true,"IPv4Forwarding":true,"BridgeNfIptables":false,"BridgeNfIp6tables":false,"Debug":false,"NFd":64,"OomKillDisable":false,"NGoroutines":82,"SystemTime":"2025-03-14T19:38:00.76514Z","LoggingDriver":"json-file","CgroupDriver":"cgroupfs","CgroupVersion":"2","NEventsListener":14,"KernelVersion":"6.10.14-linuxkit","OperatingSystem":"Docker Desktop","OSVersion":"","OSType":"linux","Architecture":"aarch64","IndexServerAddress":"https://index.docker.io/v1/","RegistryConfig":{"IndexConfigs":{"docker.io":{"Name":"docker.io","Mirrors":[],"Secure":true,"Official":true},"hubproxy.docker.internal:5555":{"Name":"hubproxy.docker.internal:5555","Mirrors":[],"Secure":false,"Official":false}},"InsecureRegistryCIDRs":["::1/128","127.0.0.0/8"],"Mirrors":null},"NCPU":8,"MemTotal":4109803520,"GenericResources":null,"DockerRootDir":"/var/lib/docker","HttpProxy":"http.docker.internal:3128","HttpsProxy":"http.docker.internal:3128","NoProxy":"hubproxy.docker.internal","Name":"docker-desktop","Labels":["com.docker.desktop.address=unix:///Users/erik/Library/Containers/com.docker.docker/Data/docker-cli.sock"],"ExperimentalBuild":false,"ServerVersion":"28.0.1","Runtimes":{"io.containerd.runc.v2":{"path":"runc"},"runc":{"path":"runc"}},"DefaultRuntime":"runc","Swarm":{"NodeID":"","NodeAddr":"","LocalNodeState":"inactive","ControlAvailable":false,"Error":"","RemoteManag
ers":null},"LiveRestoreEnabled":false,"Isolation":"","InitBinary":"docker-init","ContainerdCommit":{"ID":"bcc810d6b9066471b0b6fa75f557a15a1cbf31bb","Expected":"bcc810d6b9066471b0b6fa75f557a15a1cbf31bb"},"RuncCommit":{"ID":"v1.2.4-0-g6c52b3f","Expected":"v1.2.4-0-g6c52b3f"},"InitCommit":{"ID":"de40ad0","Expected":"de40ad0"},"SecurityOptions":["name=seccomp,profile=unconfined","name=cgroupns"],"CDISpecDirs":["/etc/cdi","/var/run/cdi"],"Warnings":["WARNING: daemon is not using the default seccomp profile"],"ClientInfo":{"Debug":false,"Version":"28.0.1","GitCommit":"068a01e","GoVersion":"go1.23.6","Os":"darwin","Arch":"arm64","BuildTime":"Wed Feb 26 10:38:16 2025","Context":"desktop-linux","Plugins":[{"SchemaVersion":"0.1.0","Vendor":"Docker Inc.","Version":"v0.21.1-desktop.2","ShortDescription":"Docker Buildx","Name":"buildx","Path":"/Users/erik/.docker/cli-plugins/docker-buildx"},{"SchemaVersion":"0.1.0","Vendor":"Docker Inc.","Version":"v2.33.1-desktop.1","ShortDescription":"Docker Compose","Name":"compose","Path":"/Users/erik/.docker/cli-plugins/docker-compose"},{"SchemaVersion":"0.1.0","Vendor":"Docker Inc.","Version":"v0.1.2","ShortDescription":"Docker Dev Environments","Name":"dev","Path":"/Users/erik/.docker/cli-plugins/docker-dev"},{"SchemaVersion":"0.1.0","Vendor":"Docker Inc.","Version":"v0.2.27","ShortDescription":"Manages Docker extensions","Name":"extension","Path":"/Users/erik/.docker/cli-plugins/docker-extension"},{"SchemaVersion":"0.1.0","Vendor":"Docker Inc.","Version":"v1.4.0","ShortDescription":"Creates Docker-related starter files for your project","Name":"init","Path":"/Users/erik/.docker/cli-plugins/docker-init"},{"SchemaVersion":"0.1.0","Vendor":"Anchore Inc.","Version":"0.6.0","ShortDescription":"View the packaged-based Software Bill Of Materials (SBOM) for an image","URL":"https://github.com/docker/sbom-cli-plugin","Name":"sbom","Path":"/Users/erik/.docker/cli-plugins/docker-sbom"},{"Name":"scan","Path":"/Users/erik/.docker/cli-plugins/docker-s
can","Err":"failed to fetch metadata: fork/exec /Users/erik/.docker/cli-plugins/docker-scan: no such file or directory"},{"SchemaVersion":"0.1.0","Vendor":"Docker Inc.","Version":"v1.16.3","ShortDescription":"Docker Scout","Name":"scout","Path":"/Users/erik/.docker/cli-plugins/docker-scout"}],"Warnings":null}}
% docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
dangerzone.rocks/dangerzone latest b725dc1f9e8d 2 months ago 1.27GB
% docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c9c5fd25a1bd: Pull complete
Digest: sha256:7e1a4e2d11e2ac7a8c3f768d4166c2defeb09d2a750b010412b6ea13de1efb19
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(arm64v8)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/
Document conversion logs
As noted, CLI works; GUI does not. This is the output from the GUI conversion. (Juicy filename aside, it's just a test doc. :)
(To be clear, I initially invoked it without the terminal, which is when I got the "unknown error".)
% /Applications/Dangerzone.app/Contents/MacOS/dangerzone NSA\ program\ update.ppt
[DEBUG] Inferred system color scheme as OSColorMode.LIGHT
qt.qpa.drawing: Layer-backing is always enabled. QT_MAC_WANTS_LAYER/_q_mac_wantsLayer has no effect.
qt.qpa.drawing: Layer-backing is always enabled. QT_MAC_WANTS_LAYER/_q_mac_wantsLayer has no effect.
[DEBUG] Setting up Dangerzone updater
[DEBUG] Consulting updater settings before checking for updates
[DEBUG] Checking platform type
[DEBUG] Checking if first run of Dangerzone
[DEBUG] Checking if user has already expressed their preference
[DEBUG] Checking for updates
[DEBUG] Checking for Dangerzone updates
[INFO] Assigning ID '8NaY50' to doc '/Users/erik/Documents/Tips/NSA program update.ppt'
[DEBUG] Removing all documents
[DEBUG] Cooling down update checks
[INFO] Assigning ID 'RutAUc' to doc '/Users/erik/Documents/Tips/NSA program update.ppt'
[DEBUG] Removing all documents
2025-03-14 12:32:20.526 dangerzone[72607:848653] +[IMKClient subclass]: chose IMKClient_Modern
[DEBUG] Marking doc RutAUc as 'converting'
[INFO] > /usr/local/bin/docker run --security-opt=no-new-privileges:true --security-opt seccomp=/Applications/Dangerzone.app/Contents/Resources/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-RutAUc dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
Usage: dangerzone [OPTIONS] [FILENAMES]...
Try 'dangerzone --help' for help.
Error: No such option: -B
[INFO] [doc RutAUc] 0% Converting page 1/3 from pixels to searchable PDF
[INFO] [doc RutAUc] 33% Converting page 2/3 from pixels to searchable PDF
[INFO] [doc RutAUc] 66% Converting page 3/3 from pixels to searchable PDF
[ERROR] [doc RutAUc] 0% Unknown error code '0'
[DEBUG] Marking doc RutAUc as 'failed'
Additional info
No response
The Error: No such option: -B is actually not the source of the error and just adds some confusion. It's tracked at https://github.com/freedomofpress/dangerzone/issues/873. It's a good reminder that we should probably investigate this further.
That [ERROR] [doc RutAUc] 0% Unknown error code '0' seem to be showing that something odd is happening. I don't really understand it. Currently investigating.
Hm, the fact that the CLI works, but the UI doesn't, reminds me of this issue: https://github.com/freedomofpress/dangerzone/issues/1073. Something seems to go on with our MacOS application.
Alexis, can you reproduce it as well? If yes, that's awesome. If not, I think we should ask from Erik to run a version with debugging info. If we can do so via a nightly build from a feature branch, instead of asking Erik to go through our build instructions, that would be the best of both worlds. What do you think?
Alexis, can you reproduce it as well?
I will have access to my macOS machine later today only, unfortunately. Using a nightly to ensure that the issue is gone on the soon to be released version seems a good option in case I can't reproduce.
Part of the reason is that pyinstaller (that we're using to package Dangerzone on macOS) is not configured properly, setting sys.executable to dangerzone, and multiprocessing is then passing options to it wrongfully thinking it's python.
I've issued a fix for this at https://github.com/freedomofpress/dangerzone/pull/1103
I've yet to understand why this is not triggered at all times, and how we've been doing conversions properly on this platform until now.
@almet Did you mean to comment the above on #873? Just checking to make sure I understand the separate issues correctly.
Happy to try with a nightly.
@eloquence I added a comment here on purpose, because the issue is at least closely related to the error you're seeing.
We don't know yet if this no such option: -B error causes the conversion to fail, but it could be, as it might mangle the output. I have a macbook m1 with me today so I'll investigate further to see if that's the end of the story: I expect there is something more.
Okay, I've been able to reproduce the error on macOS! The error happens after an upgrade to macOS 15.2, and happens only when running the OCR. This is why we see the conversion running smoothly and then failing. The other bug #873 seem unrelated, as far as I can tell.
I've been able to reproduce this bug on the latest version of Docker Desktop, for our latest 0.8.1 release and on our main branch.
~~As a quick-term mitigation, turning off the OCR on this document should make it work again~~. It seem to be a timing issue, so disabling OCR sometimes work but not consitently.
Okay, I was also able to reproduce this on my machine macOS 15.2 (24C101). ~~It does seem to be limited to specific file types (testing with .png, .pdf, even .doc all worked for me, but .docx failed).~~
Update: After some more testing, I actually did get the failure on some PDFs. Maybe the difference is multi-page vs single-page? Just a theory.
Should we issue a statement about it on Mastodon, maybe post it as a known issue on the website and suggest disabling OCR or using dangerzone-cli as a workaround until we have a fix?
I think that's a good idea. Perhaps we can edit the body of this issue with a "Temporary workaround" section similar to what we did with the previous macOS issue, and link to that from the post.
Unfortunately, the temporary workaround does not work for me consistently. I tried with a batch conversion of a docx and ppt file. Here's the output from the GUI-on-terminal run of one such conversion.
To be clear, I have definitely unchecked the OCR box on the starting screen.
If I'm interpreting correctly, it looks like it's attempting an OCR of the second file anyway.
It sometimes succeeds on both files, so there may be a race condition as well on that behavior - it's possible we're seeing compounding issues here.
/Applications/Dangerzone.app/Contents/MacOS/dangerzone
[DEBUG] Inferred system color scheme as OSColorMode.LIGHT
qt.qpa.drawing: Layer-backing is always enabled. QT_MAC_WANTS_LAYER/_q_mac_wantsLayer has no effect.
qt.qpa.drawing: Layer-backing is always enabled. QT_MAC_WANTS_LAYER/_q_mac_wantsLayer has no effect.
[DEBUG] Setting up Dangerzone updater
[DEBUG] Consulting updater settings before checking for updates
[DEBUG] Checking platform type
[DEBUG] Checking if first run of Dangerzone
[DEBUG] Checking if user has already expressed their preference
[DEBUG] Checking for updates
[DEBUG] Checking for Dangerzone updates
[DEBUG] Cooling down update checks
2025-03-18 12:44:32.318 dangerzone[80044:1168733] +[IMKClient subclass]: chose IMKClient_Modern
[INFO] Assigning ID '02tbhK' to doc '/Users/erik/Documents/Tips/Memo regarding NGOs.docx'
[INFO] Assigning ID 'h9d2pw' to doc '/Users/erik/Documents/Tips/NSA program update.ppt'
[DEBUG] Removing all documents
[DEBUG] Marking doc 02tbhK as 'converting'
[INFO] > /usr/local/bin/docker run --security-opt=no-new-privileges:true --security-opt seccomp=/Applications/Dangerzone.app/Contents/Resources/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-02tbhK dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
Usage: dangerzone [OPTIONS] [FILENAMES]...
Try 'dangerzone --help' for help.
Error: No such option: -B
[INFO] [doc 02tbhK] 0% Converting page 1/4 from pixels to PDF
[INFO] [doc 02tbhK] 25% Converting page 2/4 from pixels to PDF
[INFO] [doc 02tbhK] 50% Converting page 3/4 from pixels to PDF
[INFO] [doc 02tbhK] 75% Converting page 4/4 from pixels to PDF
[INFO] [doc 02tbhK] 100% Successfully converted document
[DEBUG] Marking doc 02tbhK as 'safe'
[DEBUG] Marking doc h9d2pw as 'converting'
[INFO] > /usr/local/bin/docker run --security-opt=no-new-privileges:true --security-opt seccomp=/Applications/Dangerzone.app/Contents/Resources/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-h9d2pw dangerzone.rocks/dangerzone /usr/bin/python3 -m dangerzone.conversion.doc_to_pixels
[INFO] [doc h9d2pw] 0% Converting page 1/3 from pixels to PDF
[INFO] [doc h9d2pw] 33% Converting page 2/3 from pixels to PDF
[INFO] [doc h9d2pw] 66% Converting page 3/3 from pixels to PDF
[ERROR] [doc h9d2pw] 0% Unknown error code '0'
[DEBUG] Marking doc h9d2pw as 'failed'
multiprocessing/resource_tracker.py:123: UserWarning: resource_tracker: process died unexpectedly, relaunching. Some resources might leak.
erik@Eriks-Air ~ % Usage: dangerzone [OPTIONS] [FILENAMES]...
Try 'dangerzone --help' for help.
Error: No such option: -B
If I'm interpreting correctly, it looks like it's attempting an OCR of the second file anyway.
I think OCR is not used on the second file. We'd see a "Converting page 1/N from pixels to searchable PDF", which is not the case. Still, we gain some info from this. It looks that if the client does not read bytes fast enough (which is especially pronounced when we do OCR for each page), the conversion will fail.
Now that I think about it, we have mostly tested dangerzone-cli without the --ocr-lang eng flag, so we haven't checked if the dangerzone-cli is racy as well. In any case, we'll dig deeper here.
After poking a bit more at this, we've been able to produce a minimal reproducible example, which shows the error we're facing:
import shlex
import subprocess
import sys
import time
# reference.txt can be generated with
# head -c 18933764 < /dev/urandom > reference.txt
command = [
"/usr/local/bin/docker",
"run",
"-v",
"./reference.txt:/tmp/reference.txt",
"--rm",
"-i",
"debian",
"bash",
"-c",
"cat /tmp/reference.txt",
]
proc = subprocess.Popen(command, stdout=subprocess.PIPE)
buffer = b""
counter = 0
while True:
current = proc.stdout.read(1000)
# Wait 1s every megabyte (approx.)
if counter % 1000 == 0:
time.sleep(1)
if not current:
break
sys.stdout.buffer.write(current)
counter += 1
When run, it returns a different number of bytes than expected:
$ cat reference.txt | wc -c
18933764
$ python ./fixme.py | wc -c
11075584
This seem to be a Docker Desktop + macOS 15.2+ specific bug. We've been able to run the same code on podman desktop without issue.
I opened an issue on the docker desktop bugtracker, that you can follow here: https://github.com/docker/for-mac/issues/7632
We got a response from upstream, and it seem that this is a CLI bug, which doesn't happen on versions prior to v27.5.1.
Meaning we have a mitigation: ask our users to not upgrade to the latest version of Docker Desktop / Provide them a download link to the versions that works.
This would be Docker Desktop 4.38.0.
As a note, it seems that my first insight, thinking that this bug was only happening on macOS was a false assumption. I've been able to reproduce this on Arch Linux with Docker 28.0.1.
This has been fixed upstream via https://github.com/docker/cli/pull/5957. I'll update this issue when a release is out (it should be 28.0.3)
Edit 2024/03/26: Docker-cli 28.0.4 is out, but not yet integrated in the Docker Desktop release. For the time being a short-term mitigation is to downgrade Docker Desktop to 4.38.0. If you use Docker for anything other than Dangerzone, please check the release notes to ensure this does not have any unintended side effects for your intended use case.
I can confirm that on macOS, downgrading to 4.38.0 resolves the issue for me, and the various conversion options (with OCR, without, etc.) all work without issue.
A new Docker Desktop release is out: https://docs.docker.com/desktop/release-notes/#4400. We'll check it out soon and verify it works.
Reopening this issue because I haven't double checked yet that the new release works. Also, on second thought, I guess we should close this issue once we have an announcement out. Might coincide with the 0.9.0 release announcement, we'll see.
I've verified that the latest Docker Desktop on an Apple Silicon macOS device solves the issue 🎉
Docker Desktop doesn't auto update immediately to latest, so let's wait till 0.9.0 (which includes a docker version check) is released to close this issue.
Closing this issue, as we just shipped Dangerzone 0.9.0, which requires a version of Docker Desktop without this bug.