Un conteneur Collabora CODE qui s'arrête immédiatement sur un hôte ARM64 utilise souvent une plateforme d'image incorrecte, mais l'architecture ARM64 en elle-même n'est pas intrinsèquement incompatible. Avant de modifier les permissions ou de reconstruire l'image, commencez par vérifier l'architecture (32 ou 64 bits) de l'hôte, le manifeste publié de l'image (tag exact) et toute substitution de plateforme Compose. Au 10 octobre 2026, l'image CODE officielle incluait des versions ARM64 ; Docker Hub répertorie le 26.04.4.2.1tag correspondant linux/arm64.
Exécutez ces commandes sur l'hôte Docker, et non à l'intérieur du conteneur Collabora arrêté. Remplacez collaborasi votre service Compose utilise un autre nom :
uname -m
docker info --format '{{.Architecture}}'
docker compose ps -a
docker compose logs --tail=100 collaboraUn hôte Linux ARM 64 bits est généralement identifié aarch64par uname -mune valeur telle que `<nom_hôte>`. Cette valeur armv7lindique généralement une plateforme noyau ARM 32 bits, différente de `< linux/arm64nom_hôte>`. L'orthographe de l'étiquette d'architecture Docker peut varier ; il est donc conseillé de comparer le type d'hôte, la configuration Compose et le manifeste de l'image plutôt que de se fier à une simple correspondance de chaînes de caractères.
Lisez le premier message d'erreur fatale et l'état de sortie. « Aucun manifeste correspondant pour linux/arm64 » signifie que l'étiquette sélectionnée ne correspond à aucune variante pour la plateforme demandée. « Erreur de format d'exécution » suggère une incompatibilité d'architecture ou l'utilisation forcée d'une plateforme étrangère. Une erreur d'autorisation ou un arrêt par manque de mémoire a une autre cause ; ne considérez pas chaque boucle de redémarrage comme un problème de compatibilité ARM.
Vérifiez l'étiquette dans le registre avant de modifier l'hôte :
docker buildx imagetools inspect collabora/code:26.04.4.2.1Recherchez cette information linux/arm64dans la liste des plateformes. Le 10 octobre 2026, la liste officielle des tags sur Docker Hub indiquait cette plateforme pour les deux versions latest. La page CODE26.04.4.2.1 de Collabora identifie les architectures hôtes x86-64, ppc64 et arm64 comme étant prises en charge. Le tag versionné facilite la reproduction du problème lors du dépannage. Les tags et les manifestes peuvent évoluer ; vérifiez donc la version exacte que vous prévoyez de déployer au lieu de supposer que tous les tags antérieurs correspondent aux mêmes architectures.
Docker sélectionne automatiquement une variante correspondante lorsque l'étiquette est multiplateforme et qu'aucune substitution ne modifie la cible. La commande d'inspection d'image de Docker affiche les plateformes publiées pour une image de registre.
Vérifiez le service Compose résolu, y compris les fichiers de remplacement, pour une configuration forcée platform: linux/amd64. La variable `docker-clic` DOCKER_DEFAULT_PLATFORMpermet également de définir la plateforme par défaut pour les commandes acceptant un indicateur de plateforme. platformLe champ `compose` sélectionne explicitement le système d'exploitation et l'architecture cibles ; supprimez donc toute configuration incorrecte ou définissez-la sur ARM64. Si vous avez `compose` jq, examinez les paramètres fusionnés sans afficher les valeurs d'environnement non pertinentes. docker compose config --format json | jq '.services.collabora | {image, platform}'La documentation du service Compose définit ce champ. `compose` DOCKER_DEFAULT_PLATFORMest documenté dans la documentation de l'interface de ligne de commande Docker .
services:
collabora:
image: collabora/code:26.04.4.2.1
platform: linux/arm64Voici un extrait : fusionnez les lignes relatives à l’image et à la plateforme dans votre service existant et conservez ses paramètres requis. Si Docker sélectionne déjà correctement le manifeste ARM64 natif, cette platformligne est facultative. Remplacez-la collaboradans les commandes ci-dessous si votre service Compose porte un autre nom.
docker compose pull collabora
docker compose up -d --force-recreate collaboraUtilisez l'étiquette épinglée comme indiqué ou une autre version dont vous venez de vérifier le manifeste. Cette latest-arm64étiquette est également répertoriée par Docker Hub, mais son contenu change à chaque nouvelle version. Épingler une version facilite la restauration et les comparaisons ultérieures. Évitez de forcer linux/amd64l'émulation comme première solution lorsqu'une image ARM64 native est disponible ; l'émulation ajoute de la surcharge et complique le diagnostic au démarrage.
Si l'image native existe toujours, utilisez le journal et l'état au lieu d'étendre les privilèges du conteneur :
| Signal | Action suivante |
|---|---|
no matching manifest | Vérifiez l'étiquette exacte et la plateforme sélectionnée ; choisissez une étiquette qui répertorie linux/arm64. |
exec format error | Supprimez la configuration AMD64, effectuez une nouvelle extraction et examinez l'architecture de l'image locale. |
permission deniedou fichier de configuration illisible | Vérifiez les fichiers et répertoires montés, leur propriétaire et leur mode, ainsi que les droits d'accès attendus du conteneur. Corrigez le montage spécifique plutôt que d'utiliser `git add` chmod -R 777ou `git add` privileged: true. |
OOMKilled=true, souvent avec le code de sortie 137 | Vérifiez la pression sur la mémoire de l'hôte et toute limite de mémoire du conteneur ; le code de sortie 137 seul ne prouve pas un arrêt par manque de mémoire. |
Utilisez le nom ou l'ID du conteneur affiché par docker compose ps -apour inspecter son état de sortie :
docker inspect --format 'status={{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} error={{.State.Error}}' CONTAINERDocker documente l'inspection des conteneurs et consulte leurs journaux pour effectuer ces vérifications. Ne supprimez pas les volumes persistants et n'attribuez pas de privilèges à l'ensemble du conteneur uniquement pour tester un problème d'architecture.
Vérifiez que l'image locale indique bien l'architecture cible :
docker image inspect collabora/code:26.04.4.2.1 --format '{{.Os}}/{{.Architecture}}'La valeur attendue est linux/arm64. Vérifiez ensuite docker compose ps -ala stabilité du système et consultez les journaux les plus récents pour détecter d'éventuelles erreurs de démarrage critiques. Une fois le conteneur connecté à votre plateforme de stockage ou à votre proxy inverse, effectuez une requête /hosting/discoveryvia l'URL Collabora configurée et ouvrez un document de test. Avant toute mise à niveau, vérifiez à nouveau la liste des étiquettes du registre, car les versions disponibles et les manifestes de plateforme peuvent évoluer.
Vérifiez l'architecture de votre hôte, assurez-vous que la balise CODE publie ARM64, supprimez les paramètres AMD64 forcés et distinguez les erreurs d'image des problèmes d'autorisation ou de mémoire.
Configurez la connexion WOPI entre Collabora Online et ownCloud Infinite Scale, configurez les URL de service appropriées et vérifiez que les modifications apportées aux documents sont enregistrées.
Empêchez l'exportation de documents dans Collabora Online CODE en définissant l'autorisation WOPI DisableExport, puis vérifiez que l'hôte et l'éditeur l'appliquent.
Configurez la terminaison TLS Nginx, les routes Collabora et les en-têtes WebSocket, puis testez les points de terminaison publics avant d'ouvrir les documents réels.
Identifiez la cause d'une déconnexion CODE de 10 minutes : proxy, équilibreur de charge ou chemin WebSocket, puis corrigez le délai d'expiration et vérifiez que la session reste connectée.
Installez le graphique Helm officiel de Collabora, configurez l'accès WOPI et l'affinité d'entrée, et vérifiez le déploiement sans erreurs de configuration courantes.
Utilisez les requêtes du navigateur, les journaux WOPI et les vérifications de proxy ciblées pour déterminer pourquoi Collabora ouvre un document vierge et choisissez une solution adaptée aux éléments de preuve.
Configurez correctement les dictionnaires Docker de CODE et les passages de documents étiquetés afin que l'anglais, le français et les autres langues prises en charge bénéficient d'une correction orthographique appropriée.
Ajustez le seuil d'inactivité par vue dans coolwsd et distinguez-le de l'assombrissement des onglets en arrière-plan, du déchargement des documents, de la sauvegarde automatique et de l'expiration de la connexion.
Interrompez les vérifications de mise à jour du code planifiées, examinez les services distants optionnels et utilisez les contrôles réseau sortants sans interrompre l'édition des documents.
