Startseite
» MS OFFICE
»
Fix Collabora CODE Container Failing to Start on ARM64 Architecture
Fix Collabora CODE Container Failing to Start on ARM64 Architecture
If a Collabora Online Development Edition (CODE) container exits immediately on an ARM64 machine, start with architecture compatibility before changing networking, certificates, or WOPI settings. As of October 7, 2026, the official collabora/code repository lists native linux/arm64 variants for current releases, including the current latest tag and version 26.04.4.2.1. That means a modern ARM64 host normally does not need x86 emulation just to run CODE. The most useful beginner workflow is to confirm the host architecture, inspect the exact image tag, remove any forced AMD64 setting, pull an ARM64-capable image, and only then troubleshoot application-level configuration.
This guide focuses on the startup failure itself. It does not assume that every ARM64 problem has the same cause. If the container starts successfully but Nextcloud, ownCloud, or another WOPI host cannot connect to it, that is a different layer of troubleshooting.
What you need to know before changing anything
ARM64 is a 64-bit ARM CPU architecture. Linux commonly reports it as aarch64, while Docker usually labels the same target as linux/arm64. AMD64, also called x86-64, is a different CPU architecture. A container image contains binaries built for one or more architectures; Docker can automatically select the correct variant only when the image tag provides a compatible manifest.
A multi-platform image is a single image tag whose registry manifest points to separate image builds for architectures such as AMD64 and ARM64. Docker documents that, when a multi-platform image is pulled, it selects the matching variant for the host automatically. See Docker's multi-platform image documentation for the underlying behavior.
For Collabora CODE specifically, check the official collabora/code tag list on Docker Hub rather than relying on an old tutorial. When this article was checked on October 7, 2026, latest and 26.04.4.2.1 included linux/arm64, and a dedicated latest-arm64 tag was also listed. Older pinned releases may differ, so the tag you actually deploy matters more than a general claim that “Collabora supports ARM.”
Prepare a safe troubleshooting session
Keep a copy of your current docker-compose.yml or deployment command.
Record the exact Collabora image tag you are using.
Do not delete application data or reverse-proxy configuration just to diagnose an architecture mismatch.
If this is a production deployment, test a replacement tag in a maintenance window or on a staging host first.
The target result is simple: Docker should pull an ARM64 image, the container should remain running instead of exiting immediately, and its logs should progress into normal Collabora startup rather than fail with an architecture error.
Step 1: Confirm the host and Docker architecture
Run these checks on the machine that actually runs the Collabora container:
uname -m
docker info --format '{{.Architecture}}'
docker version
On a native 64-bit ARM Linux host, uname -m commonly returns aarch64, while Docker should report arm64. These names refer to the same architecture family in this context.
Check both the operating system and Docker daemon architecture first. A native ARM64 host typically appears as aarch64 in Linux and arm64 in Docker.
If Docker reports AMD64 even though the physical machine is ARM64, determine whether you are using a remote Docker context, a virtual machine, or Docker Desktop with a different backend. Fix that ambiguity before continuing. Otherwise you may inspect one system while deploying to another.
What error points to an architecture mismatch?
Typical signals include exec format error, a registry message that there is no matching manifest for linux/arm64, or a Compose service explicitly configured with platform: linux/amd64. These messages are stronger evidence of a platform mismatch than generic “container exited” output.
Step 2: Inspect the exact Collabora image tag before pulling it
Do not assume that every historical tag has the same platform support as today's latest. Inspect the registry metadata for the tag in your deployment:
Inspect the image manifest and look specifically for linux/arm64. Current official CODE tags can be multi-platform, but an older pinned tag may not be.
If linux/arm64 appears, you can use the multi-platform tag and let Docker select the correct image. For an explicit troubleshooting test, the official repository also lists latest-arm64. For long-lived production deployments, an exact versioned tag that you have tested is usually easier to reproduce than latest, because latest moves as new releases are published.
If your pinned tag does not include ARM64, you have three choices:
Choice
Best fit
Tradeoff
Move to a current native ARM64 CODE tag
Most ARM64 servers and home labs
You must validate release compatibility and your integration settings
Stay on the old release using AMD64 emulation
Short-term compatibility testing
Extra complexity and possible performance overhead; not the preferred fix when a native image exists
Keep the old release on an AMD64 host
Strict version pinning where upgrade risk is unacceptable
Requires different hardware or VM capacity
Step 3: Remove an accidental AMD64 override and pull cleanly
Ein häufiger Fehler liegt nicht am Collabora-Image selbst, sondern an einer Bereitstellungsdatei, die die falsche Plattform erzwingt. Docker Compose definiert platformals Zielbetriebssystem und -architektur die Auswahl der Image-Variante. Die Compose-Dienstreferenz von Docker zeigt Werte wie beispielsweise linux/arm64/v8…
Auf einem ARM64-Host ist diese Einstellung verdächtig:
Wenn Sie keine Emulation benötigen, entfernen Sie diese Zeile und lassen Sie Docker die native Host-Variante auswählen. Alternativ können Sie platform: linux/arm64die Architektur explizit angeben, wenn Sie sie explizit festlegen möchten.
Ein Fehler im Ausführungsformat ist ein starker Hinweis darauf, dass eine AMD64-Binärdatei auf einem ARM64-System ohne geeigneten Emulationspfad ausgewählt wurde.
Entfernen Sie anschließend nur den fehlerhaften Container und laden Sie das Image erneut herunter. Löschen Sie keine persistenten Daten, es sei denn, es gibt einen triftigen Grund dafür.
docker compose down
docker image rm collabora/code:latest 2>/dev/null || true
docker pull --platform linux/arm64 collabora/code:latest
docker compose up -d
Wenn Sie für einen Diagnoselauf das dedizierte Architektur-Tag verwenden, ersetzen Sie es collabora/code:latest-arm64. Sobald Sie die erfolgreiche Bereitstellung bestätigt haben, sollten Sie eine exakte Version, z. B. ein getestetes 26.04.x-Tag, festlegen, anstatt ein Produktivsystem auf einem sich ändernden Tag zu belassen.
Schritt 4: Überprüfen Sie, ob CODE startet, bevor Sie die Integration debuggen.
Nach dem Neuerstellen des Containers Status und Protokolle überprüfen:
Bei einer Bereitstellung mit einem einzelnen Container lauten die entsprechenden Befehle docker ps -aund docker logs --tail=100 <container-name>.
Ein korrigierter Compose-Dienst sollte auf einem ARM64-Host nicht linux/amd64 erzwingen. Lassen Sie ein Multiplattform-Tag automatisch auflösen oder wählen Sie linux/arm64 bei Bedarf explizit aus.
Ihr erstes Erfolgskriterium ist, dass der Container weiterhin läuft und keine Manifest- oder Ausführungsformatfehler mehr auftreten. Erst danach sollten Sie sich mit der Erreichbarkeit von Port 9980, den Reverse-Proxy-Einstellungen, TLS, zulässigen WOPI-Hosts oder der Anwendungsintegration befassen. Die offizielle CODE-Docker-Dokumentation von Collabora ist die richtige Anlaufstelle, um die aktuellen Bereitstellungsparameter zu überprüfen.
Häufige Anfängerfehler, die es zu vermeiden gilt
Installieren Sie QEMU, bevor Sie das offizielle Image überprüfen.
Emulation kann hilfreich sein, wenn Software nur für eine andere CPU-Architektur existiert. Die aktuellen Collabora CODE-Images enthalten jedoch ARM64-Varianten. Das Hinzufügen von Emulation kann das eigentliche Problem verschleiern und führt zu einer zusätzlichen Komplexität. Bevorzugen Sie native ARM64-Unterstützung, sofern Ihre benötigte CODE-Version diese bietet.
Angenommen, „neueste“ und ein altes Etikett sind gleichwertig
Die Plattformverfügbarkeit ist an ein bestimmtes Image-Tag und Manifest gebunden. Ein aktuelles Tag kann ARM64 unterstützen, eine ältere Version hingegen nicht. Überprüfen Sie den genauen Verweis in Ihrer Compose-Datei.
Plattform erzwungen: linux/amd64, da dies in einer älteren Anleitung verwendet wurde.
Das kann dazu führen, dass ein ARM64-Host die x86-64-Variante verwendet, selbst wenn ein natives ARM64-Image vorhanden ist. Entfernen Sie die Überschreibung, es sei denn, Sie haben einen triftigen und getesteten Grund für die Emulation.
Ändern der WOPI-, SSL- oder Proxy-Einstellungen, bevor der Prozess ausgeführt werden kann
Ein exec format errorFehler tritt auf, bevor Collabora die meisten Konfigurationen auf Anwendungsebene sinnvoll verarbeiten kann. Die Architekturauswahl sollte zuerst korrigiert werden. Netzwerk- und WOPI-Probleme können später behoben werden.
Datenvolumen während der Diagnose löschen
Architekturinkompatibilitäten erfordern normalerweise keine Löschung persistenter Daten. Halten Sie den Korrekturumfang gering, damit ein Rollback problemlos möglich bleibt.
Was passiert, wenn das ARM64-Image weiterhin existiert?
Wenn das Manifest diese Variante eindeutig enthält linux/arm64und Docker diese Variante abruft, ist die Architektur nicht mehr die Hauptursache. Erfassen Sie in diesem Fall Folgendes:
docker compose psoderdocker ps -a
die letzten 100-200 Logzeilen
das genaue CODE-Tag
Ihre Docker Engine- und Compose-Versionen
die nicht geheimen Teile Ihrer Compose-Dienstdefinition
Untersuchen Sie anschließend Berechtigungen, eingebundene Pfade, Sicherheitsprofile, Speicherauslastung, Portkonflikte, Zertifikate oder die WOPI-Konfiguration anhand der jeweiligen Protokollmeldung. Vermeiden Sie wiederholte Architekturwechsel, sobald Sie sichergestellt haben, dass das laufende Image ARM64 ist.
Ein praktischer Entscheidungsweg
Wenn der Host nicht ARM64 ist, verwenden Sie keine ARM64-spezifische Lösung mehr und ermitteln Sie die tatsächliche Plattform.
Wenn der Host ARM64 ist, das gewählte CODE-Tag aber kein ARM64-Manifest hat, wechseln Sie zu einem unterstützten nativen Tag oder wählen Sie bewusst eine andere Hosting-Strategie.
Wenn das Tag ARM64 unterstützt, Compose aber AMD64 erzwingt, entfernen oder korrigieren Sie die platformEinstellung.
Falls das korrekte ARM64-Image weiterhin nicht angezeigt wird, behandeln Sie dies als normales Collabora-Startproblem und folgen Sie den Protokollen, anstatt weiterhin die CPU-Architektur zu beschuldigen.
Fazit
Auf einem modernen ARM64-System ist Emulation in der Regel nicht die bevorzugte Lösung. Wie am 7. Oktober 2026 bestätigt wurde, enthalten die aktuellen offiziellen Collabora-CODE-Tags native ARM64-Images. Überprüfen Sie aarch64die arm64korrekte Konfiguration auf dem Host, prüfen Sie das genaue Image-Manifest, entfernen Sie veraltete oder erzwungene AMD64-Referenzen, laden Sie das ARM64-kompatible Image erneut herunter und stellen Sie sicher, dass der Container weiterhin ausgeführt wird. Diese Vorgehensweise gestaltet die Fehlersuche anfängerfreundlich und verhindert, dass irrelevante SSL-, Proxy- oder WOPI-Änderungen eine grundlegende Plattforminkompatibilität verschleiern.