Pourquoi Nextcloud ? Nextcloud
fournit un espace personnel pour stocker, synchroniser et partager ses fichiers depuis plusieurs
appareils, via une interface web et des clients dédiés.
Pourquoi l'auto-hébergement ? Il permet de garder la maîtrise du lieu de stockage,
du cycle de mise à jour et des règles d'accès. En contrepartie, il faut assurer soi-même la disponibilité, le
durcissement, la capacité disque, les sauvegardes et les tests de restauration.
🧩 Architecture mise en œuvre
- VM Ubuntu 24.04 dédiée au service (VM205)
- Un conteneur Docker pour l'application Nextcloud
- Un conteneur Docker distinct pour MariaDB
- Deux volumes Docker séparant fichiers applicatifs et base de données
- Autodémarrage de la VM après les services prioritaires, puis reprise des deux conteneurs
- Publication HTTPS derrière le reverse proxy mutualisé (VM200)
🎯 Compétences mises en œuvre
- Exploitation d'une application auto-hébergée dans une VM Proxmox
- Séparation applicative Nextcloud / MariaDB
- Persistance par volumes Docker
- Diagnostic croisé systemd · Docker · HTTP · outil
occ - Construction d'une preuve reproductible et assainie après redémarrage
🌐 Publication HTTPS validée
Nextcloud est accessible sous nextcloud.stephanemuraro.fr. Le service conserve son
authentification propre tandis que le reverse proxy (VM200) centralise la terminaison TLS
et relaie les requêtes vers la VM applicative.
Validé depuis un réseau extérieur :
- établissement de la connexion HTTPS
- authentification
- consultation des fichiers
- téléversement d'un fichier par l'interface web
- synchronisation par le client de bureau
Le diagnostic préalable a isolé deux extensions applicatives défaillantes, neutralisées de façon
réversible afin de restaurer l'interface puis les écritures, sans supprimer les données.
🔄 Preuve reproductible — état après redémarrage
Exécutées dans la VM, ces commandes déterminent automatiquement le nom du conteneur et le port local publié — la preuve ne dépend donc pas des libellés propres à l'installation.
bash — contrôle d'état
date --iso-8601=seconds
systemctl is-system-running
systemctl --failed --no-pager
nextcloud_container=$(
sudo docker ps --filter ancestor=nextcloud --format '{{.Names}}' | head -n 1
)
nextcloud_port=$(
sudo docker port "$nextcloud_container" 80/tcp | awk -F: 'NR == 1 {print $NF}'
)
sudo docker ps --format \
'table {{.Image}}\t{{.Status}}' | awk 'NR == 1 || /nextcloud|mariadb/'
sudo docker exec -u www-data "$nextcloud_container" php occ status
curl -fsS "http://127.0.0.1:${nextcloud_port}/status.php"extrait assaini — validation après redémarrage de l'hôte
Horodatage : 2026-08-15T07:51:40+00:00 État système : running Unités systemd en échec : 0 nextcloud Up About an hour mariadb Up About an hour installed: true versionstring: 33.0.0 maintenance: false needsDbUpgrade: false productname: Nextcloud
Lecture :
occ status et le point d'état HTTP confirment Nextcloud 33.0.0
installé, hors maintenance et sans migration de base en attente. La présence simultanée des conteneurs
Nextcloud et MariaDB après redémarrage démontre leur reprise automatique.
Limites & travaux ouverts :
- Volumes Docker sur le disque système de la VM — le stockage ZFS dédié envisagé n'est pas encore monté/utilisé.
- Capacité libre du disque système à surveiller avant croissance importante des données.
- Sauvegardes indépendantes et test de restauration : pas encore démontrés.
- Chaîne d'analyse antivirus à redéployer sous forme persistante avant réactivation de son extension Nextcloud.
- Connecteur de stockage externe neutralisé à remplacer par une version compatible ou à retirer définitivement.