Contexte : cloud privé (fichiers, agendas, contacts) publié sur cloud.massyl.fr · Testé sur : CT 105, Nextcloud 34 (PHP 8.4), MariaDB 10.11, Docker Compose · Dernière vérification : 01/10/2026
| Élément | Valeur |
|---|---|
| Machine | CT 105 Nextcloud-PCT-105, 192.168.1.105 (DHCP et bail statique), CT non privilégié avec nesting, démarrage automatique activé |
| Système du CT | Ubuntu 20.04 (relevé du 30/09/2026) |
| Logiciel | Nextcloud 34 (image nextcloud:34, PHP 8.4, Apache) et MariaDB 10.11 dans un second conteneur |
| Déploiement | Docker Compose, projet /opt/nextcloud (docker-compose.yml et .env, lisibles par root uniquement) |
| Port publié | 8080 (HTTP), relayé par le reverse proxy |
| URL publique | https://cloud.massyl.fr |
| Données | /path/to/nextcloud/data, environ 711 Go au 30/09/2026 |
| Proxy de confiance | trusted_proxies = 192.168.1.210 (CT 210) ; overwriteprotocol = https |
| État | en marche |
Le chemin
/path/to/nextcloud/dataest le chemin réel des données : c'est un exemple de documentation jamais remplacé lors de l'installation, pas une erreur de cette page.
sudo pct exec 105 -- <commande> ou sudo pct enter 105..env du projet, jamais dans le wiki.L'outil d'administration occ s'exécute dans le conteneur nextcloud, sous l'utilisateur www-data. Depuis l'hôte, une fonction shell évite de retaper le préfixe :
occ() { sudo pct exec 105 -- docker exec -u www-data nextcloud php occ "$@"; }
occ status
occ config:system:get trusted_domains
occ update:check
Sur les opérations lourdes (analyse de fichiers, nettoyage), occ peut saturer la mémoire PHP : ajoutez -d memory_limit=-1 juste après php dans la fonction.
sudo pct exec 105 -- sh -c 'cd /opt/nextcloud && docker compose ps'
sudo pct exec 105 -- sh -c 'cd /opt/nextcloud && docker compose logs --tail 50'
Depuis le CT 210, sans dépendre du DNS public :
sudo pct exec 210 -- curl -sk -H "Host: cloud.massyl.fr" https://127.0.0.1/status.php
La réponse JSON doit contenir "installed":true et "maintenance":false.
Après une sauvegarde :
sudo pct exec 105 -- sh -c 'cd /opt/nextcloud && docker compose pull && docker compose up -d'
occ status
occ upgrade
occ app:update --all
Le conteneur applique lui-même la migration au démarrage ; occ upgrade ne sert que si occ status indique qu'une mise à niveau reste nécessaire. Le passage à une version majeure suivante se fait une version à la fois.
/path/to/nextcloud/data/nextcloud.log.sudo pct exec 210 -- sh -c 'grep -i mirall /var/log/nginx/access.log | tail -5'
Avant de conclure à une panne de Nextcloud, vérifiez dans ce journal si le client atteint vraiment le serveur : le 28/09/2026, un « délai d'attente dépassé » venait d'une panne IPv4 de la box, pas de Nextcloud.
Aucune sauvegarde externe des données (environ 711 Go) ni de la base. Seules copies : le dump et le snapshot
avant-securisation-20261001faits le 01/10/2026, et un ancien dump de juin 2026, tous sur le même disque que les données.
Plan de sauvegarde recommandé (3-2-1) :
occ maintenance:mode --on), faire un dump cohérent de la base depuis le conteneur MariaDB, copier config.php, puis sortir de maintenance (occ maintenance:mode --off) ;vzdump en mode snapshot ou par Proxmox Backup Server, ou par restic ou Borg, vers une destination externe à l'hôte (prévoir environ 720 Go) ;docker-compose.yml et .env lisibles par root uniquement.sudo pct set 105 --description '').Travaux réalisés le 01/10/2026, chacun vérifié après application.
Sauvegardes préalables
config.php et du compose dans /root/backup-nextcloud-20261001/ (droits root, 0600).avant-securisation-20261001 du CT 105.Mises à jour
Performance
nextcloud-redis, sans port publié, avec mot de passe) : cache distribué et verrous de fichiers. Fin des erreurs « file is locked » de la synchronisation.occ db:add-missing-indices, 02/10/2026).cron avec un timer systemd nextcloud-cron.timer (toutes les 5 min). Les tâches étaient bloquées depuis 2023 (environ 328 000 en attente) ; 60 000 entrées de géolocalisation photo en échec permanent ont été retirées de la file.Rétention de la corbeille et des versions temporairement désactivée (
trashbin_retention_obligationetversions_retention_obligation=disabled) pour que la reprise des tâches de fond ne supprime rien. Pour revenir à la règle d'origine (90 jours) :occ config:system:set trashbin_retention_obligation --value="auto, 90"puisocc config:system:set versions_retention_obligation --value="auto".
Réseau et exposition
DOCKER-USER, service nc-firewall.service).ServerTokens Prod, PHP expose_php = Off, côté proxy server_tokens off et en-tête X-Powered-By retiré.Sécurité applicative
admin_audit, fichier data/audit.log), détection des connexions suspectes (suspicious_login). Le journal d'audit est forcé par log.condition (apps => admin_audit) : il reste actif même avec le niveau de journal général à 2.DenyKey=system.run[*]), serveur repointé vers 192.168.1.107 (02/10/2026).Nettoyage
mysql.service, mariadb.service et script SysV) : elle ne redémarre plus au boot.config.php.old (2023, contenant des secrets) retiré du volume web et rangé dans la sauvegarde root.nextcloud.log de 1,7 Go archivé et compressé, rotation automatique à 100 Mo.Habillage 2S Innovation
Reste à faire (action de Mass)
mass et massadmin.| Date | Changement |
|---|---|
| 04/2023 | Mise en service (Nextcloud 26) |
| 24/06/2026 | Montée de version progressive jusqu'à Nextcloud 34, précédée d'un dump SQL |
| 28/09/2026 | Clients de synchronisation en échec (« délai d'attente dépassé ») : cause identifiée, panne IPv4 de la box |
| 30/09/2026 | Adresse passée à 192.168.1.105 (DHCP et bail statique), trusted_domains mis à jour ; audit de sécurité en lecture seule |
| 01/10/2026 | Dump et snapshot avant travaux, puis sécurisation (voir ci-dessus) |