CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF /

Nextcloud : ajouter une adresse à trusted_domains

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

Un navigateur qui demande Nextcloud par une adresse absente du tableau trusted_domains reçoit une page d’erreur à la place de l’écran de connexion. Ce tableau vit dans le fichier config/config.php de l’installation, où l’assistant a inscrit localhost et le nom d’hôte utilisé le jour de l’installation. La commande occ y ajoute une entrée sans rouvrir le fichier PHP, ce qui évite les guillemets manquants et les virgules oubliées. Les autres logiciels libres auto-hébergés du même genre sont classés dans la rubrique logiciels.

Sommaire
  1. Le message « Access through untrusted domain » désigne la clé trusted_domains
  2. Trois commandes occ ajoutent l’adresse à la liste
  3. Une valeur sans port accepte tous les ports, une valeur avec port ferme les autres
  4. Un fichier en .config.php du dossier config écrase config.php sans message
  5. Les liens de partage suivent le nom d’hôte qui a servi à les copier
  6. Sources

Le message « Access through untrusted domain » désigne la clé trusted_domains

Nextcloud refuse les requêtes dont l’en-tête Host ne figure pas dans trusted_domains, un tableau du fichier config/config.php que le manuel d’administration présente comme une protection contre l’empoisonnement de l’en-tête Host. Le gabarit de page core/templates/untrustedDomain.php du dépôt nextcloud/server porte le texte affiché dans ce cas, en anglais, sans numéro d’erreur à recopier ni commande suggérée. La cause tient donc à une seule valeur : le nom demandé, port compris, ne correspond à aucune entrée de la liste, et l’écran de connexion n’est jamais servi. Le refus tombe avant toute vérification de mot de passe, et l’adresse tapée dans le navigateur suffit à le déclencher. Une différence entre deux versions du manuel mérite l’attention. Celui de Nextcloud 28 ne mentionnait qu’une adresse de bouclage exemptée, 127.0.0.1 ; celui de Nextcloud 35 nomme localhost, 127.0.0.1 et [::1] comme toujours considérées comme sûres, même absentes de la liste.

Access through untrusted domain
Please contact your administrator. If you are an administrator, edit the "trusted_domains" setting in config/config.php like the example in config.sample.php.
Further information how to configure this can be found in the documentation.

Ce contrôle porte sur l’URL demandée, pas sur l’origine du visiteur. Le manuel précise que trusted_domains n’est pas une liste des domaines ou des adresses IP autorisés côté client : inscrire l’adresse du poste de travail ne débloque rien tant que le navigateur appelle le serveur par un autre nom.

Derrière un répartiteur de charge, la même page exige du proxy qu’il transmette un en-tête X-Forwarded-Host correct, sans quoi le nom reçu ne correspondra pas à la liste. Les en-têtes d’une requête HTTP et le rôle de l’en-tête Host sont détaillés dans comprendre HTTP.

Trois commandes occ ajoutent l’adresse à la liste

La commande occ remplace l’édition manuelle du fichier, et le manuel d’administration impose deux conditions à son lancement. Elle doit tourner sous l’utilisateur HTTP, www-data sur Debian et Ubuntu, avec le même interpréteur PHP que le serveur web. L’exécution en root est la faute courante : la documentation demande l’utilisateur HTTP pour que les droits sur le fichier et sur le dossier de données restent cohérents. Le script se trouve dans le dossier de l’installation, /var/www/nextcloud dans l’exemple du manuel. Sous Arch, le wiki documente d’autres chemins, /etc/webapps/nextcloud/config/config.php pour le fichier et une enveloppe /usr/bin/occ qui bascule d’elle-même sur l’utilisateur nextcloud. Les valeurs citées ici valent pour Nextcloud 35 sous Debian et Ubuntu, la version 35.0.0 étant publiée le 16 septembre 2026 selon la page de changelog du projet.

  1. Lire la liste en place, puisque le premier index libre se déduit du nombre d’entrées.

    cd /var/www/nextcloud
sudo -u www-data php occ config:system:get trusted_domains

    À l’écran : une entrée par ligne, localhost en premier sur une installation neuve. Deux lignes affichées signifient deux index occupés, 0 et 1 ; l’index libre suivant est 2.

  2. Écrire l’adresse au premier index libre, en reprenant l’orthographe exacte du nom utilisé dans le navigateur.

    sudo -u www-data php occ config:system:set trusted_domains 2 --value=cloud.example.com

    À l’écran : System config value trusted_domains => 2 set to string cloud.example.com. La confirmation nomme la clé, l’index et la valeur retenue. Le même index réécrit une entrée existante au lieu d’en ajouter une, comme dans l’exemple du manuel, où une liste de trois entrées reçoit sa troisième valeur par un index 2.

  3. Relire la liste, puis recharger la page refusée.

    sudo -u www-data php occ config:system:get trusted_domains

    À l’écran : le tableau compte une ligne de plus, à l’index demandé, et le navigateur affiche l’écran de connexion au lieu du message d’erreur. Si l’accès reste refusé, la cause est à chercher dans le dossier de configuration, pas dans la commande.

Une valeur sans port accepte tous les ports, une valeur avec port ferme les autres

Les formes acceptées dans trusted_domains ne couvrent pas le même terrain, et le manuel d’administration Nextcloud 35 les énumère dans la référence des paramètres de configuration. Un nom d’hôte seul, cloud.example.com, accepte ce nom sur tous les ports. Le même nom suivi d’un port, cloud.example.com:443, n’accepte que ce port et désactive les autres, ce que le document écrit en une ligne. Un joker se place à l’intérieur d’un nom : l’exemple du manuel, ubos-raspberry-pi*.local, accepte ubos-raspberry-pi.local et ubos-raspberry-pi-2.local. L’adresse IPv6 se note entre crochets, [2001:db8::1]:8080. Toute autre notation laisse l’entrée sans effet, et le message d’erreur revient à l’identique. Le manuel de la version 28 s’arrêtait à la phrase « vous pouvez utiliser des adresses IP et des noms de domaine » ; celui de la version 35 ajoute les jokers et la notation entre crochets.

Forme inscrite dans trusted_domains Hôtes acceptés Ports acceptés
cloud.example.com ce nom exact tous les ports de ce nom
cloud.example.com:443 ce nom exact le port 443 uniquement
ubos-raspberry-pi*.local les noms qui commencent et finissent ainsi, dont ubos-raspberry-pi.local et ubos-raspberry-pi-2.local tous les ports de ces noms
192.168.1.50 cette adresse IPv4 tous les ports
[2001:db8::1]:8080 cette adresse IPv6 le port 8080 uniquement

Un joker employé seul couvrirait tous les hôtes, ce qui annule la protection contre l’empoisonnement de l’en-tête Host que le manuel associe à ce paramètre. Le même document demande de ne pas retirer ce réglage. Ce nom inscrit commande aussi le certificat présenté au navigateur, question traitée dans le certificat TLS d’un Nextcloud.

Un fichier en .config.php du dossier config écrase config.php sans message

Une commande occ confirmée à l’écran peut ne rien changer à l’accès, parce que le dossier config/ charge d’autres fichiers après config.php. Le manuel d’administration décrit cette mécanique : tout fichier dont le nom se termine par .config.php est fusionné à la configuration, et ses valeurs l’emportent toujours sur celles de config/config.php. Ce même document signale le piège du nom de sauvegarde. Une copie de config.php déposée dans ce dossier et nommée avec cette terminaison est lue comme configuration active et écrase les valeurs du fichier principal, sans que rien ne le signale à l’écran. La commande peut donc réussir, la relecture de config/config.php montrer la nouvelle entrée, et l’accès rester refusé. Seule la configuration fusionnée fait foi, celle que le manuel fait afficher par occ config:list system.

Deux causes voisines vivent dans le même dossier. La variable d’environnement NEXTCLOUD_CONFIG_DIR déplace l’ensemble du dossier de configuration, et le manuel impose de la définir à la fois pour le serveur web et pour occ : quand elle est posée, le config/config.php du dossier d’installation n’est plus lu. Le code de la commande, dans core/Command/Config/System/SetConfig.php, remplace par un tableau vide toute valeur existante qui n’en est pas un avant d’écrire l’index demandé : une clé transformée en chaîne de caractères repart d’une liste neuve.

Les liens de partage suivent le nom d’hôte qui a servi à les copier

Que se passe-t-il si la valeur inscrite ne porte pas le même port que l’URL ?

Une entrée sans port accepte son nom sur tous les ports, tandis qu’une entrée avec port ferme les autres, comme l’écrit le manuel. La liste qui contient cloud.example.com:443 refuse donc l’accès par https://cloud.example.com:8443, alors que l’entrée cloud.example.com accepte les deux. Le geste de contrôle tient en une comparaison : le nom et le port affichés dans la barre du navigateur doivent se retrouver tels quels dans la liste.

Peut-on écrire toute la liste en une seule commande ?

Oui, avec le type json. Le manuel donne cette forme : occ config:system:set trusted_domains --type json --value '["nextcloud.local","example.com"]', et la confirmation affiche la liste complète. La commande remplace le tableau entier : localhost disparaît alors du fichier, même si l’adresse de bouclage reste acceptée. L’option --type est à manier avec précaution, le manuel précisant qu’une erreur de type peut casser l’instance.

Faut-il passer par occ ou par un éditeur de texte ?

Les deux voies sont prévues par le manuel, qui autorise la modification de config.php dans un éditeur et décrit en parallèle les commandes de l’espace config:system. La commande occ évite d’écrire la syntaxe du tableau à la main ; le manuel note qu’une entrée mal formée ne produit pas forcément d’erreur immédiate et peut donner des résultats inattendus. L’éditeur reste la voie de secours quand occ ne peut pas tourner, faute d’accès à l’interpréteur PHP en ligne de commande.

Une deuxième adresse d’accès casse-t-elle les liens de partage ?

Avec plusieurs entrées dans trusted_domains, le manuel explique que Nextcloud accepte les requêtes sur toutes et construit ses URL à partir du nom d’hôte de la requête reçue. Un lien copié depuis l’adresse interne, par exemple cloud.local, porte ce nom et reste hors de portée des utilisateurs qui n’ont accès qu’à l’adresse publique. Le remède documenté tient en deux valeurs, overwritehost et overwrite.cli.url, à poser au nom public pour que tous les liens générés pointent au même endroit.

La commande a réussi et l’accès reste refusé, où regarder ?

Dans le dossier config/, où un fichier terminé par .config.php peut imposer une autre liste : ses valeurs l’emportent sur celles de config/config.php, et une copie de sauvegarde nommée selon cette terminaison est chargée comme configuration active. Le manuel fait afficher cette configuration fusionnée par occ config:list system, enrichi de --private pour les valeurs sensibles. La variable NEXTCLOUD_CONFIG_DIR expliquerait une absence totale d’effet : elle déplace le dossier de configuration, et le fichier du dossier d’installation n’est alors plus lu.

Sources