Un écran blanc sur ownCloud est un symptôme, pas un diagnostic. La meilleure solution dépend de la cause du problème : erreur serveur, réception de code HTML valide mais échec du chargement de JavaScript ou CSS, ou tentative d’accès à un proxy inverse incapable d’atteindre ownCloud.
Cette distinction est importante car les compromis sont très différents. Désactiver une application tierce présente un risque relativement faible lorsqu'une exception PHP mentionne cette application. Modifier le propriétaire des fichiers sur l'ensemble d'une installation est beaucoup plus intrusif et ne devrait pas être la première réaction face à une erreur JavaScript. De même, redémarrer tous les services peut masquer temporairement un problème sans permettre de déterminer s'il provient de PHP, d'un proxy, d'une mise à jour ou d'une application.
Ce guide concerne ownCloud Classic. D'après la documentation actuelle d'ownCloud Classic 11, cette version est prise en charge pour un déploiement basé sur Docker, avec le système d'exploitation, l'environnement d'exécution PHP, la base de données et Apache dans des conteneurs fournis par ownCloud. Les installations 10.x plus anciennes peuvent encore utiliser une architecture traditionnelle avec serveur web et PHP-FPM. Utilisez la branche de commandes correspondant à votre déploiement. Consultez la configuration système requise pour ownCloud Classic 11 .
Ouvrez les outils de développement de votre navigateur et examinez les onglets Réseau et Console . Testez également le point de terminaison depuis un terminal :
curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/
Légende : Une réponse 500 côté serveur indique un problème avec ownCloud, PHP, la base de données ou la pile web plutôt qu’un simple problème de rendu du navigateur.
Si le document principal renvoie une erreur 500 ou 502/503 , vérifiez en priorité les journaux du serveur et du proxy. Si le document principal renvoie une erreur 200 mais que les modules JavaScript échouent avec des erreurs 404, 403 ou des exceptions de script, vérifiez en priorité les chemins d'accès aux ressources, la réécriture du proxy inverse, les thèmes, le cache ou la compatibilité de l'application. Si un seul navigateur est concerné, testez en navigation privée et avec un autre navigateur compatible avant de changer de serveur.
Il s'agit d'une question cruciale car elle permet de cibler immédiatement la source du problème. Les notes de version actuelles d'ownCloud indiquent qu'ownCloud Classic 11 requiert désormais la version minimale de PHP 8.3 et qu'il est exclusivement compatible avec Docker. Une installation ownCloud 10.x antérieure suit des règles de compatibilité PHP différentes ; par conséquent, ne reprenez pas les recommandations PHP d'une version majeure précédente.
Pour une installation ownCloud 10.x classique, exécutez la commande depuis le répertoire ownCloud :
sudo -u www-data ./occ status
php -vPour ownCloud Classic 11, exécutez OCC via le déploiement Compose :
docker compose exec owncloud occ status
docker compose exec owncloud php -v
Légende : Vérifier les versions installées d’ownCloud et de PHP est particulièrement important lorsque l’écran blanc apparaît immédiatement après une mise à jour.
Comparez le résultat avec les notes de version de la version que vous utilisez. Les notes de version officielles d'ownCloud constituent la source de référence pour connaître les versions minimales requises et les changements importants. Une rétrogradation n'est pas une solution sûre : la documentation d'ownCloud indique que cette opération n'est pas prise en charge car elle peut corrompre les données.
Les journaux sont généralement plus utiles que les modifications de configuration par tâtonnement. Le manuel d'administration d'ownCloud recommande l'utilisation du journal d'ownCloud pour le diagnostic des problèmes ; par défaut, ce journal est stocké dans le répertoire de données configuré, sauf indication contraire logfile.
Dans une installation traditionnelle, on peut citer comme exemples :
tail -n 100 /path/to/owncloud/data/owncloud.log
journalctl -u php-fpm --since "15 minutes ago"
journalctl -u apache2 --since "15 minutes ago"
journalctl -u nginx --since "15 minutes ago"Sur ownCloud Classic 11, examinez plutôt les services Compose :
docker compose logs --tail=200 owncloud
docker compose ps
Légende : Une erreur fatale PHP ou une trace de pile qui nomme une application ou une classe constitue une cible de dépannage beaucoup plus sûre que la modification de paramètres serveur sans rapport.
Recherchez la première exception fatale liée à l'échec de la requête, et non seulement la cascade d'erreurs finale. Les causes fréquentes incluent une classe PHP manquante, une application incompatible, un échec de connexion à la base de données, une configuration illisible, des fichiers de code manquants ou une exception lors d'une mise à niveau inachevée.
La documentation de journalisation d'ownCloud indique que le niveau de journalisation DEBUG peut être utile lors du diagnostic, mais qu'il génère un volume important de données et peut impacter les performances. Si vous augmentez temporairement le niveau de journalisation, rétablissez-le à une valeur moins détaillée une fois les informations recueillies. Consultez la configuration de la journalisation d'ownCloud .
Choisissez cette option si l'erreur concerne une application non essentielle, si la page blanche s'affiche après l'installation ou la mise à jour d'une application, ou si l'erreur survient lors d'une mise à niveau d'ownCloud. Les instructions de dépannage d'ownCloud recommandent explicitement de désactiver les applications tierces pour le dépannage et avant les mises à niveau.
Lister les applications en premier. Sur ownCloud 10.x :
sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_IDSur ownCloud 11 :
docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID
Légende : Désactiver uniquement l’application concernée par les journaux est moins perturbateur que de désactiver de nombreux composants ou de modifier l’ensemble de la pile Web.
Le compromis réside dans la perte de fonctionnalités : les utilisateurs perdent l’accès à l’application jusqu’à sa mise à jour ou sa réactivation. Cette solution est généralement préférable à la désactivation des services essentiels d’ownCloud. La documentation OCC précise également que plusieurs applications essentielles ne peuvent pas être désactivées, notamment DAV, FederatedFileSharing, Files et Files_External. Consultez le guide de dépannage général officiel et le manuel de référence des commandes OCC .
Les permissions sont fortement suspectées lorsque le journal contient des erreurs Permission denied, par exemple lorsqu'un déploiement récent a copié des fichiers app/config avec le mauvais utilisateur, ou lorsqu'une mise à jour a remplacé des fichiers dont le propriétaire était incorrect. Elles sont faiblement suspectées lorsque la seule preuve est une erreur JavaScript côté navigateur.
Mettez le système en mode maintenance avant toute intervention de réparation perturbatrice. Pour ownCloud 11 :
docker compose exec owncloud occ maintenance:mode --onPour un déploiement 10.x traditionnel :
sudo -u www-data ./occ maintenance:mode --on
Légende : Le mode maintenance réduit l’activité des utilisateurs pendant que vous examinez les erreurs de propriété ou d’autorisation de fichiers déjà étayées par les journaux d’événements.
N'exécutez pas de chmod 777recette de permissions récursive globale ni ne copiez les recettes d'une version non liée. Le manuel ownCloud 11 actuel documente la propriété et les modes spécifiques des fichiers ajoutés manuellement dans les répertoires montés Dockerapps : configpropriété www-data:root, fichiers d'application 0644, répertoires d'application 0751et fichiers de configuration ajoutés 0644. Il documente également les modifications 0640manuelles apportées aux permissions . Utilisez la documentation de mise à niveau manuelle d'ownCloud 11 comme référence spécifique à cette version..htaccess.user.ini
Uniquement lorsque les journaux ou les tests de compatibilité le confirment. Cette solution a des conséquences bien plus importantes que la désactivation d'une seule application défectueuse. Une extension PHP requise manquante peut empêcher l'exécution du code, tandis qu'une configuration PHP malformée peut affecter toutes les applications PHP hébergées.
Pour une pile PHP héritée gérée par l'hôte, examinez ce que le moteur d'exécution Web charge réellement :
php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable
Légende : Les vérifications des modules PHP et d’OPcache sont utiles lorsque les journaux du serveur signalent des extensions manquantes ou une incompatibilité d’exécution, mais elles ne doivent pas constituer la première modification apportée sans preuve.
Pour ownCloud 11, l'image officielle gère l'environnement d'exécution PHP ; modifier les paquets PHP de l'hôte est donc généralement une mauvaise approche. La documentation d'ownCloud indique qu'OPcache est activé par défaut dans son image Docker. Consultez la documentation relative à la mise en cache en mémoire d'ownCloud .
Si vous soupçonnez un cache d'opcode obsolète après le remplacement manuel de fichiers PHP sur une installation ancienne, le redémarrage de PHP-FPM ou du service web/PHP concerné peut vider le cache d'opcode local au processus. Cette opération entraîne une brève interruption et une baisse des performances après le redémarrage. Procédez à cette opération après avoir corrigé les fichiers sous-jacents, et non comme substitut à l'identification de l'erreur.
Si une page blanche apparaît pendant ou immédiatement après une mise à jour, vérifiez d'abord l'état de la mise à jour. La documentation de mise à jour d'ownCloud recommande d'utiliser OCC pour la procédure de mise à jour et de réparation plutôt que de manipuler la base de données manuellement.
Pour ownCloud 11 :
docker compose exec owncloud occ status
docker compose exec owncloud occ upgrade
docker compose exec owncloud occ maintenance:repair
docker compose exec owncloud occ integrity:check-corePour ownCloud 10.x, utilisez les commandes OCC équivalentes sous l'utilisateur du serveur web :
sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core
Légende : La réparation OCC est appropriée en cas de mise à niveau interrompue ou incohérente, tandis que les contrôles d’intégrité peuvent identifier les fichiers de base signés modifiés ou manquants.
Les résultats d'intégrité du code nécessitent une interprétation. La documentation ownCloud INVALID_HASHprésente ces résultats FILE_MISSINGcomme EXTRA_FILEdes conditions distinctes. Ne modifiez pas les paramètres signature.jsonpour faire disparaître les avertissements. La documentation ownCloud 11 actuelle rend également la signature des applications tierces obligatoire pour l'installation, les mises à jour et l'activation. Consultez la documentation ownCloud sur la signature du code .
Une bonne récupération ne se résume pas à « la page n’est plus blanche ». Vérifiez l’intégralité du chemin de la requête :
occ statussignale une instance installée et aucune exigence de mise à niveau inattendue.Pour ownCloud 11 :
docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/
Légende : La récupération doit être confirmée aux deux niveaux : l’interface ownCloud se charge et les vérifications d’état côté serveur et HTTP restent valides.
| Preuve que vous avez | Meilleur premier choix | Compromis |
|---|---|---|
| Un seul navigateur affiche la page blanche | Fenêtre privée, prise en charge d'un second navigateur, console du navigateur | Risque minimal ; ne résout pas un véritable problème de serveur si tous les utilisateurs sont affectés |
| Le document principal est une erreur HTTP 500 | journaux ownCloud, PHP/conteneur, serveur web et base de données | Méthode la plus rapide pour identifier la cause racine ; nécessite un accès aux journaux système ou de la plateforme. |
| L'erreur désigne une application tierce | Désactivez uniquement cette application avec OCC | Risque opérationnel généralement faible, mais les fonctionnalités de cette application sont temporairement indisponibles. |
| Le problème a commencé immédiatement après la mise à jour. | Vérifiez la matrice des versions prises en charge, l'état de la mise à niveau, la compatibilité des applications et la réparation OCC. | Plus contrôlé qu'une restauration ; peut nécessiter une période de maintenance. |
| Les journaux indiquent une erreur d'autorisation après la copie des fichiers. | Correct uniquement les informations de propriété/modes documentées pour la version concernée | Précis lorsqu'il existe des preuves ; les modifications d'autorisations récursives et généralisées peuvent engendrer des problèmes de sécurité et de mise à niveau. |
| Le contrôle d'intégrité du noyau signale des fichiers modifiés/manquants | Restaurez les fichiers de version corrects ou suivez la procédure de mise à niveau/restauration prise en charge | Préserve l'intégrité ; évite de modifier manuellement de nombreux fichiers principaux directement sur place |
| HTTP 200 mais échec JS/CSS | Réseau/Console du navigateur, chemins proxy, ressources du thème/de l'application, cache | Évite les modifications inutiles de la base de données/PHP ; peut nécessiter un accès à la configuration du proxy |
display_errorssur un site de production public uniquement pour exposer les traces de pile au navigateur ; utilisez plutôt les journaux du serveur.signature.jsondans le seul but de supprimer les erreurs d'intégrité.Cessez toute modification si les journaux indiquent une corruption de la base de données, des problèmes de clés de chiffrement, des défaillances répétées de l'intégrité du noyau après une restauration complète, ou un état de mise à niveau impossible à finaliser avec la procédure OCC documentée. Signalez également le problème si la page blanche affecte un cluster de production et qu'il est impossible d'isoler un nœud sans compromettre la cohérence des données.
Avant d'ouvrir un ticket d'assistance, ownCloud recommande de rassembler un rapport de configuration et les journaux pertinents. Pour ownCloud 10.x, la commande documentée est :
sudo -u www-data ./occ configreport:generate > config_report.txtUtilisez la méthode d'exécution OCC appropriée à votre déploiement et vérifiez la présence de secrets dans les journaux avant de les partager en dehors de votre organisation. Le guide de collecte des journaux et de la configuration d'ownCloud explique les informations généralement nécessaires aux ingénieurs de support.
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.
