Rédigé par Rédaction CyberSDF / 19 September 2026

chown www-data : remettre les droits de Nextcloud après une migration

plusieurs fenetres abstraites en aplats geometriques qui se recouvrent, vue de face

Internal Server Error cache quatre messages différents

Internal Server Error après une migration Nextcloud vient du propriétaire des fichiers, pas du code. Une arborescence copiée ou restaurée en root prive le processus PHP de l’accès en écriture à config/ et à data/. Quand config/config.php est illisible, PHP s’arrête et la réponse se limite à la page 500 du serveur web. Sinon, quatre messages peuvent s’afficher : Cannot write into « config » directory., Your data directory is not writable., Your data directory is readable by other people., et Your data directory is invalid., qui ne parle pas de droits mais d’un fichier témoin absent. Les chemins testés sont lus dans config/config.php, donc la correction ne dépend pas de l’endroit où l’installation a été posée. Le manuel d’administration Nextcloud 35 fixe la règle pour les trois premiers : le compte du serveur web doit pouvoir lire et écrire dans chaque dossier.

Sommaire

Internal Server Error cache quatre messages différents
Reprendre le propriétaire, puis les modes, puis le dossier data
occ s’arrête si le compte appelant n’est pas celui de config.php
Le contrôle du dossier data se corrige une fois tout seul
data/ en lien symbolique : chown -R suit la cible
Les cas où le chown ne suffit pas
Sources

Un dossier data inaccessible coupe aussi la trace écrite, puisque la documentation de occ log:file montre le journal rangé dans le dossier data. Les quatre contrôles sortent de la fonction checkServer, exécutée à chaque requête. Le même genre de panne attend les autres services auto-hébergés de la rubrique Logiciels.

Les quatre contrôles de permissions de Nextcloud, la valeur acceptée et la valeur qui déclenche le message.
Chemin contrôlé	Valeur acceptée	Valeur refusée	Message littéral
data/ (racine du dossier)	dernier chiffre du mode à 0, soit 0770	0755, 0775, 0707	Your data directory is readable by other people. Please change the permissions to 0770 so that the directory cannot be listed by other people.
data/.ncdata	fichier présent, contenu # Nextcloud data directory	fichier absent, ou nommé .ocdata	Your data directory is invalid. Ensure there is a file called « .ncdata » in the root of the data directory.
config/ (dossier)	lisible et inscriptible par le compte du serveur web	root:root en 0755	Cannot write into « config » directory.
data/ (écriture réelle)	la création d’un fichier temporaire aboutit	l’ouverture du fichier échoue	Your data directory is not writable.
config/config.php	propriétaire identique au compte qui lance occ	occ lancé par root	Console has to be executed with the user that owns the file config/config.php

Reprendre le propriétaire, puis les modes, puis le dossier data

Le chown à lancer dépend de l’emplacement réel du dossier data, que le manuel de mise à niveau manuelle de Nextcloud 35 rappelle à son étape 13 : chown -R www-data:www-data sur l’arborescence, puis 750 sur les dossiers et 640 sur les fichiers. Cette étape ne couvre pas le cas où data/ a été sorti de l’installation, puisque son chemin est alors inscrit dans config/config.php. La séquence ci-dessous ajoute les deux vérifications que cette documentation ne détaille pas : le compte qui possède réellement config.php, et le fichier témoin qui valide le dossier data. Elle suppose une installation dans /var/www/nextcloud et un compte nommé www-data, la valeur par défaut sous Debian et Ubuntu. Aucun redémarrage de PHP ni du serveur web n’est nécessaire après un chown, les modes étant relus à chaque ouverture de fichier.

Relever le propriétaire et le mode du fichier de configuration, référence des contrôles suivants.
```
stat -c '%U:%G %a %n' /var/www/nextcloud/config/config.php
```
Ce que vous devez voir : une ligne du type www-data:www-data 640 /var/www/nextcloud/config/config.php. Un root en première colonne annonce l’échec des commandes occ lancées sans changer d’utilisateur.
Reprendre le propriétaire sur toute l’installation.
```
sudo chown -R www-data:www-data /var/www/nextcloud
```
Ce que vous devez voir : rien. L’affichage fichier par fichier est réservé à l’option -v de chown(1) ; sans elle, seules les erreurs passent à l’écran.
Lister ce qui n’appartient toujours pas au compte du serveur web.
```
sudo find /var/www/nextcloud ! -user www-data -print -quit
```
Ce que vous devez voir : aucune sortie. Un chemin affiché désigne un fichier que chown n’a pas pu changer, typiquement sur un montage distant.
Appliquer les deux modes du manuel, un pour les dossiers, un pour les fichiers.
```
sudo find /var/www/nextcloud/ -type d -exec chmod 750 {} \;
sudo find /var/www/nextcloud/ -type f -exec chmod 640 {} \;
```
Ce que vous devez voir : rien, puis ls -ld /var/www/nextcloud qui affiche drwxr-x—.
Traiter le dossier data à part, avec le mode 0770 attendu par le contrôle.
```
sudo grep datadirectory /var/www/nextcloud/config/config.php
sudo chown -R www-data:www-data /var/www/nextcloud/data
sudo chmod 0770 /var/www/nextcloud/data
```
Ce que vous devez voir : la première commande renvoie la valeur réelle de datadirectory, et ls -ld sur ce chemin affiche drwxrwx—.
Vérifier le fichier témoin du dossier data, et le créer s’il manque.
```
sudo -u www-data ls -l /var/www/nextcloud/data/.ncdata
echo '# Nextcloud data directory' | sudo -u www-data tee /var/www/nextcloud/data/.ncdata
```
Ce que vous devez voir : une ligne en -rw-r—– si le fichier existe ; la seconde commande ne sert que dans le cas contraire et réaffiche # Nextcloud data directory.
Relancer les deux commandes de contrôle sous le compte du serveur web.
```
cd /var/www/nextcloud
sudo -E -u www-data php occ status
sudo -E -u www-data php occ setupchecks
```
Ce que vous devez voir : – installed: true et – maintenance: false sur la première sortie, et des lignes précédées d’une coche sur la seconde, dont Data directory protected.

Tous les systèmes ne nomment pas ce compte www-data. Sur Arch, le paquet crée un compte nommé nextcloud, propriétaire de /var/lib/nextcloud/data, et le lanceur /usr/bin/occ change d’utilisateur lui-même : la référence reste le propriétaire de config.php relevé au point 1. Quand le chown est refusé, le manuel d’installation donne la sortie de secours, usermod -a -G vboxsf www-data, qui ouvre le dossier au groupe.

occ s’arrête si le compte appelant n’est pas celui de config.php

Lancer occ avec sudo sans changer d’utilisateur échoue sur une comparaison d’identifiants, et aucune commande ne part. Le script console.php du dépôt officiel lit l’identifiant du compte courant avec posix_getuid, le compare à celui que fileowner renvoie pour config/config.php, puis affiche le message d’arrêt et sort avec le code 1. La documentation des commandes occ donne la forme attendue, sudo -E -u www-data, l’option -E transmettant les variables d’environnement, et elle rappelle que le compte HTTP change selon la distribution : www-data sous Debian et Ubuntu, apache sous Fedora et CentOS, http sous Arch, wwwrun avec le groupe www sous openSUSE. L’appel peut partir de n’importe quel répertoire, le script se replaçant lui-même dans le dossier de l’installation avant de travailler. En conteneur, où sudo et su manquent parfois, la même documentation propose runuser –user www-data — /usr/bin/php occ.

Console has to be executed with the user that owns the file config/config.php
Current user id: 0
Owner id of config.php: <identifiant du propriétaire>
Try adding 'sudo -u #<identifiant du propriétaire>' to the beginning of the command (without the single quotes)

Ces deux identifiants sont remplacés par les valeurs du système au moment de l’exécution. Un config.php resté à root après une restauration déclenche ce message même quand tous les dossiers sont corrects. La page consacrée à installer Nextcloud chez soi détaille la préparation du reste de la pile.

Le contrôle du dossier data se corrige une fois tout seul

Sur la racine du dossier data, Nextcloud tente la correction avant de se plaindre. La fonction checkDataDirectoryPermissions lit le dernier chiffre du mode en octal, appelle chmod($dataDirectory, 0770) si ce chiffre n’est pas zéro, relit la valeur, et ne renvoie un message que si le chiffre reste différent de zéro. Un dossier resté en 0775 ou en 0755 passe donc sans intervention lorsque le processus PHP en est propriétaire, et le bandeau disparaît au rechargement suivant. Le réglage check_data_directory_permissions, lu dans config/config.php avec la valeur true par défaut, désactive ce contrôle sur les systèmes de fichiers qui ne savent pas porter de modes Unix. Deux limites subsistent : le test ne porte que sur la racine du dossier data, jamais sur les sous-dossiers, et il ne regarde que le dernier chiffre du mode.

Un sous-dossier data/appdata resté en 0777 ne produit aucun message, le contrôle de la racine étant satisfait. C’est ce que couvre le chown récursif du point 5. Les bits utilisés ici sont les permissions de Nextcloud, avec 4 pour la lecture, 2 pour l’écriture et 1 pour la traversée.

data/ en lien symbolique : chown -R suit la cible

Le manuel chown(1) livré avec coreutils 9.1 sur Debian 12 déclare –dereference comme comportement par défaut et -P comme mode de traversée par défaut. Un chown -R posé sur une arborescence qui contient un lien vers un autre volume change donc le propriétaire des fichiers de ce volume, pas celui du lien. Sur une installation Nextcloud, le cas se produit quand data/ a été installé sur un disque séparé au moyen d’un lien symbolique, méthode que la documentation Arch cite parmi les façons de sortir les données du disque système. La commande garde alors sa cible : sudo chown -R www-data:www-data /var/www/nextcloud suit le lien et attribue tout le volume à www-data. L’option -h limite le changement au lien lui-même, précaution utile sur un volume qui héberge autre chose que Nextcloud.

Une variante évite de parcourir ce qui est déjà correct : –from=CURRENT_OWNER:CURRENT_GROUP, du même manuel, ne change un fichier que si son propriétaire actuel correspond. Après une migration, sudo chown -R –from=root:root www-data:www-data /var/www/nextcloud ne touche que les fichiers restés à root. Le repérage préalable se fait avec find et son test -user.

Les cas où le chown ne suffit pas

Faut-il changer le propriétaire ou seulement les modes ?

Le propriétaire. La documentation d’installation de Nextcloud 35 exige que le compte du serveur web puisse lire et écrire dans les dossiers, et précise que la propriété n’est pas strictement nécessaire : quand le chown est impossible, elle fait ajouter ce compte au groupe propriétaire avec usermod -a -G.

Pourquoi occ refuse-t-il de tourner après une restauration ?

Parce que config/config.php a été restauré en root alors que la commande part du compte www-data, ou l’inverse. Le script compare les deux identifiants avant d’exécuter quoi que ce soit : la correction porte sur le fichier, sudo chown www-data:www-data /var/www/nextcloud/config/config.php.

Comment vérifier en une commande que plus rien n’appartient à root ?

sudo find /var/www/nextcloud ! -user www-data -print -quit n’affiche rien quand tout est correct, et s’arrête au premier chemin fautif. Le contrôle des permissions passe ensuite par sudo -E -u www-data php occ setupchecks, qui marque d’une coche les contrôles réussis.

Le message disparaît-il tout seul si je ne fais rien ?

Oui, si le compte PHP est propriétaire du dossier data et que seul le dernier chiffre du mode cloche : le contrôle applique lui-même chmod($dataDirectory, 0770), puis relit la valeur. Un chmod lancé par un compte qui n’est pas propriétaire échoue sans bruit, et le message revient à chaque requête.

Pourquoi créer .ocdata ne corrige-t-il pas Your data directory is invalid ?

Le contrôle de la branche stable35 cherche un autre nom : la fonction checkDataDirectoryValidity teste l’existence de .ncdata, dont le contenu attendu est # Nextcloud data directory. La création se fait depuis le dossier data, avec echo et sudo -u www-data tee.