Si ownCloud affiche « Échec du contrôle d'intégrité » après une mise à jour, consultez le rapport de fichiers invalides pour identifier l'élément défaillant avant de modifier les fichiers. Une nouvelle analyse ne fait que répéter la vérification ; elle ne restaure pas les fichiers manquants, n'annule pas les modifications personnalisées et n'installe pas une version corrigée de l'application. Pour les fichiers principaux, comparez-les avec la version exacte d'ownCloud vers laquelle vous avez effectué la mise à jour. En cas de problème de signature d'une application, recherchez une mise à jour compatible et correctement signée ou contactez son responsable.
La réparation appropriée dépend de la portée de l'avertissement. Remplacer l'intégralité de l'installation peut s'avérer plus sûr après une mise à niveau partielle ou mixte, mais cela implique une interruption de service plus longue et une préservation rigoureuse des données de configuration et des données utilisateur. Remplacer un seul fichier système confirmé est plus rapide, à condition de pouvoir vérifier que ce fichier appartient bien à la version installée. Désactiver la validation de signature peut rendre une application spécifique utilisable, mais cela réduit la protection et doit constituer une exception documentée, et non une solution de routine.
Connectez-vous en tant qu'administrateur et ouvrez la page d'administration. Suivez l'avertissement d'intégrité pour accéder à la liste des fichiers invalides. Dans la documentation ownCloud actuelle, le rapport regroupe les problèmes par composant, comme les fichiers principaux ou une application, et utilise des étiquettes telles que «INVALID_HASH composant », FILE_MISSING« chemin » EXTRA_FILEet EXCEPTION« erreur ». Ces étiquettes indiquent différentes causes ; notez donc le composant, le chemin et l'erreur avant d'effectuer des modifications.
INVALID_HASHCela signifie que le contenu actuel d'un fichier ne correspond pas au hachage de sa signature. Les explications courantes incluent une mise à jour partielle, un ancien fichier resté en place ou une modification locale.FILE_MISSINGCela signifie qu'un fichier signé est absent. Une extraction ou un déploiement d'archive incomplet peut en être la cause.EXTRA_FILECela signifie que l'installation contient un fichier non répertorié dans la signature. Il peut s'agir d'un résidu accidentel, d'un fichier personnalisé ou d'un ajout local légitime nécessitant une vérification.EXCEPTIONCela signifie qu'ownCloud n'a pas pu vérifier la signature. Le rapport peut indiquer que les données de signature sont manquantes, que le certificat est invalide ou révoqué, ou que la vérification n'a pas pu aboutir.Ne supprimez pas un fichier simplement parce qu'il apparaît comme superflu. Vérifiez sa fonction et qui l'a ajouté. En particulier, ne modifiez jamais le fichier de configuration d'une application signature.jsonpour faire disparaître l'avertissement ; les recommandations d'ownCloud concernant la signature de code indiquent clairement de ne pas le modifier.
| Trouver | Prochaine étape souhaitée | Compromis |
|---|---|---|
| Plusieurs fichiers principaux présentent des hachages invalides ou sont manquants après une mise à niveau manuelle. | Créez une nouvelle copie de la version cible exacte et restaurez les fichiers officiels affectés, ou répétez la mise à niveau manuelle proprement. | Une mise à niveau propre demande plus de travail et peut nécessiter une interruption de service, mais réduit le risque de laisser une arborescence de code à versions mixtes. |
| Un fichier principal est invalide et vous savez qu'il a été modifié localement. | Comparez la modification avec le fichier de version correspondant ; conservez la modification personnalisée en dehors de l’arborescence principale signée et réappliquez-la uniquement si elle est prise en charge. | Conserver la modification peut préserver le comportement local, tandis que la modification des fichiers principaux signés continuera d'entraîner l'échec des contrôles d'intégrité. |
| Une application signale des données de signature manquantes ou invalides | Installez une version compatible fournie par le responsable de l'application ou désactivez/supprimez l'application si vous n'en avez plus besoin. | Une mise à jour préserve les fonctionnalités ; la désactivation évite de modifier le code de l’application, mais peut supprimer des fonctionnalités essentielles pour les utilisateurs. |
| Le certificat de l'application est révoqué ou invalide. | Demandez au responsable de l'application une nouvelle version compatible signée ; ne réutilisez pas et ne modifiez pas les fichiers de signature. | Cela peut prendre du temps, mais la validation de la signature reste intacte. |
| Un fichier supplémentaire a été identifié. | Vérifiez son propriétaire, son objectif et s'il fait partie d'une personnalisation avant de le déplacer hors du répertoire d'installation. | La suppression d'un fichier inconnu peut perturber une intégration locale ou supprimer des données importantes. |
ownCloud 11 introduit une contrainte spécifique à cette version : les applications tierces doivent posséder des signatures valides pour être installées, mises à jour ou activées. Une application non valide peut être bloquée et non plus simplement signalée. À compter du 6 octobre 2026, la documentation d'ownCloud 11.0 indique que les applications utilisant l'ancien système de signature sont acceptées avec un avertissement jusqu'au 31 décembre 2026 ; après cette date, seules les signatures conformes à la nouvelle infrastructure à clés publiques (PKI) sont acceptées. Si vous utilisez ownCloud 10.x, veuillez consulter la documentation correspondant à votre version exacte au lieu de supposer que les règles d'application de la version 11.0 s'appliquent.
Ces précautions sont importantes car un avertissement d'intégrité concerne le code exécutable de l'application, tandis que la base de données et les fichiers utilisateur constituent des éléments distincts de l'installation. Restaurer un ancien répertoire de code par-dessus des fichiers plus récents gérés par le système de gestion de paquets peut engendrer des incompatibilités. Les instructions de mise à niveau d'ownCloud recommandent d'effectuer une sauvegarde récente, de consulter les notes de version et les exigences, et de vérifier la compatibilité des applications tierces avant toute mise à niveau.
Si le rapport mentionne des chemins d'accès officiels aux fichiers principaux, tels que index.php`/ version.phpetc/core`, `/etc/core` ou `/etc/core`, sous l'arborescence principale, téléchargez l'archive officielle correspondant à la version exacte que vous souhaitez exécuter. N'utilisez pas une archive plus récente simplement parce qu'elle est disponible : les hachages d'intégrité correspondent à une version spécifique.
En cas de petite incohérence facilement identifiable, comparez le chemin d'accès signalé avec le même chemin dans l'archive. Après avoir confirmé qu'il s'agit d'un fichier officiel non modifié, remplacez uniquement le fichier concerné en veillant à conserver les droits d'accès et les permissions requis par votre serveur web. Si plusieurs fichiers sont manquants ou incohérents, ou si vous ne parvenez pas à déterminer la version ayant fourni les fichiers actifs, une mise à niveau complète à partir d'un répertoire de distribution récent est généralement la solution la plus fiable.
Pour une installation manuelle d'archive, la méthode la plus sûre consiste à préparer la version séparément, à préserver les fichiers configet datales répertoires, puis à suivre la procédure de mise à niveau officielle pour déployer le code. Ne remplacez pas le répertoire de données utilisateur par le contenu de l'archive. Les déploiements de packages et de conteneurs disposent de leurs propres procédures de mise à jour ; utilisez-les plutôt que d'appliquer la méthode d'archivage manuel. Si vous transférez des fichiers individuels par FTP, la documentation d'intégrité d'ownCloud spécifie le mode de transfert binaire.
Si le rapport mentionne une application plutôt que le noyau, vérifiez d'abord sa compatibilité avec votre version d'ownCloud. Installez une version officielle ou fournie par un mainteneur, compatible avec le serveur et comportant une signature valide. Si aucune version compatible n'est disponible, désactivez l'application et assurez-vous que cela n'interrompra pas un flux de travail essentiel. La suppression d'une application est une solution plus définitive et doit être effectuée conformément à la procédure de suppression propre à l'application.
Pour ownCloud 11, la désactivation de la validation d'une application est une exception gérée par l'administrateur, consignée dans un journal et qui entraîne la perte de la protection contre la révocation et l'annulation de l'application. N'utilisez cette option qu'après avoir évalué la source et l'impact de l'application, et documenté l'auteur de l'autorisation et sa justification. Cette méthode ne permet pas de réparer une installation corrompue ou altérée. Pour les versions antérieures, le comportement de contrôle diffère ; consultez la documentation de votre version.
Après avoir corrigé les fichiers sous-jacents, utilisez la fonction de nouvelle analyse de la page d'administration si elle est disponible. Vous pouvez également exécuter les occvérifications documentées. Pour Docker Compose, le guide de signature de code ownCloud actuel fournit les exemples suivants :
docker compose exec owncloud occ integrity:check-core
docker compose exec owncloud occ integrity:check-app calendarRemplacez calendarpar l'identifiant de l'application indiqué dans votre rapport. Pour les installations hors conteneur, exécutez le occfichier depuis votre répertoire ownCloud en tant qu'utilisateur du serveur web ; le chemin d'accès et l'utilisateur exacts varient selon le système d'exploitation et la méthode d'installation. La commande documentée vérifie l'application principale ou une application spécifique ; le guide actuel indique qu'il n'existe pas de commande unique permettant de réanalyser manuellement toutes les applications.
Une réparation est validée lorsqu'un nouveau rapport ne mentionne plus les fichiers corrigés et que la fonctionnalité concernée fonctionne normalement. Si la même erreur de hachage persiste, vérifiez s'il s'agit d'un déploiement automatisé, d'un correctif local, d'une tâche de synchronisation ou d'un incident de sécurité modifiant à nouveau le fichier. Si le rapport signale un certificat révoqué, une signature d'application manquante ou une incompatibilité de version non résolue par une version officielle, interrompez l'analyse et contactez le responsable de l'application ou le support ownCloud en leur fournissant le rapport et la version exacte du serveur.
Choisissez un remplacement ciblé lorsque le rapport identifie un fichier principal officiel, que la version exacte est connue et que vous pouvez vous procurer le fichier original correspondant. Répétez la mise à niveau complète si de nombreux fichiers principaux échouent, si la mise à niveau a été interrompue ou si l'installation contient des fichiers provenant de plusieurs versions. Pour les erreurs affectant uniquement une application, privilégiez une mise à jour par un responsable de la maintenance ou la désactivation d'une application inutilisée ; cela corrige le problème du composant affecté sans remplacer les fichiers principaux non liés. Réservez les exceptions de validation à une application spécifique et évaluée lorsqu'il n'existe aucun remplacement signé et que le besoin opérationnel justifie la perte de protection de l'intégrité.
Avant la prochaine mise à jour, consultez les notes de version et la configuration requise, désactivez les applications tierces incompatibles comme recommandé par ownCloud et effectuez une nouvelle sauvegarde. Ces étapes nécessitent un peu de préparation, mais elles facilitent le diagnostic des alertes d'intégrité après la mise à jour et sécurisent la restauration.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
