Fichiers exposés après mise à jour de nextcloud?

Mon serveur YunoHost

Matériel: VPS acheté en ligne
Version de YunoHost: 11.2.15
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer:
mise à jour de nextcloud 28.0.6~ynh1 vers 29.0.2~ynh1
logs de la mise à jour à toutes fin utiles : https://paste.yunohost.org/raw/wubeyucixu

Description du problème

Depuis la mise à jour de Nexcloud j’ai ce nouveau message d’erreur dans le vue d’ensemble du panneau d’administration de nextcloud :

Votre dossier de données et vos fichiers sont probablement accessibles depuis internet. Le fichier .htaccess ne fonctionne pas. Nous vous recommandons vivement de configurer votre serveur web de façon à ce que ce dossier de données ne soit plus accessible, ou de le déplacer hors de la racine du serveur web.

Dois je m’inquiéter ?

2 Likes

Bonjour,

J’ai ce même avertissement dans le même contexte avec un port ssh exotique.

Résumé
  • Votre dossier de données et vos fichiers sont probablement accessibles depuis internet. Le fichier .htaccess ne fonctionne pas. Nous vous recommandons vivement de configurer votre serveur web de façon à ce que ce dossier de données ne soit plus accessible, ou de le déplacer hors de la racine du serveur web.

  • Votre serveur web n’est pas configuré correctement pour résoudre les URL .well-known, a échoué sur : /.well-known/caldav Pour plus d’information, voir la documentation :arrow_upper_right:.

  • La vérification d’intégrité a été désactivée. L’intégrité ne peut pas être vérifiée.

Faut-il temporairement restaurer la sauvegarde de “pre-upgrade” ?

ppr

Sounds related to this issue

Est spécifique des serveurs apache. Yunohost utilise nginx qui n’utilise pas htaccess mais une configuration spécifique (/etc/nginx).

Le message d’erreur est nouveau. Je me demande s’il n’y a pas eu un oubli de vérifier le type de serveur Web avant d’afficher ce message.
Il vaut mieux poser la question du côté de nextcloud

Je me rappelle avoir eu ce problème, si je me rappelle bien j’avais du supprimer localhost des trusted_domains dans le fichier de configuration Nextcloud

2 Likes

Bonjour, j’ai le même message d’alerte, effectivement je pensais que .htaccess était un fichier de protection pour serveur Apache?? nos fichiers sont-ils vulnérables??

En effet, j’ai supprimé la ligne localhost :

  'trusted_domains' =>
  array (
    1 => 'nextcloud.domaine.ndd',
  ),

Cela semble résoudre le problème.

2 Likes

Alors, je vois la question posé dans la chatroom : quel fichier ?

sudo yunohost app shell nextcloud

Puis
nano config/config.php

4 Likes

merci, c’était bien ça qui cassait les liens caldav cardav…

Par contre j’ai laissé le premier lien 0 plutôt

  'trusted_domains' =>
  array (
   0 => 'nextcloud.domaine.ndd',
  ),

1 Like

Merci beaucoup ça fonctionne pour moi aussi. Merci Jarod5001 pour les commandes de modification prètes à l’emploi dans un terminal en SSH, modification du fichier en 2 mn!

1 Like

J’ai fait la même chose.

0 => 'nextcloud.domaine.ndd',

Par contre plusieurs clients de synchronisation ne fonctionnent plus du coup !!!

Le commentaire de @ericg n’est pas sans intérêt… pour réparer des clients de synchro j’ai du faire cela

location ^~ /.well-known {
  # The following 6 rules are borrowed from `.htaccess`

  # The following 2 rules are only needed for the user_webfinger app.
  # Uncomment it if you're planning to use this app.
  #rewrite ^/\.well-known/host-meta\.json  /public.php?service=host-meta-json  last;
  #rewrite ^/\.well-known/host-meta        /public.php?service=host-meta       last;

#  location = /.well-known/carddav     { return 301 /remote.php/dav/; }
#  location = /.well-known/caldav      { return 301 /remote.php/dav/; }
  
  location = /.well-known/webfinger     { return 301 /index.php$request_uri; }
  location = /.well-known/nodeinfo      { return 301 /index.php$request_uri; }

  # Let Nextcloud's API for `/.well-known` URIs handle all other
  # requests by passing them to the front-end controller.
  return 301 /index.php$request_uri;
}

location /.well-known/carddav {
    return 301 https://nextcloud.domaine.tld/remote.php/dav/;
}

location /.well-known/caldav {
    return 301 https://nextcloud.domaine.tld/remote.php/dav/;
}

comme expliqué ici

Très bizarre !!

Et aussi j’ai eu quelques fois un de mes utilisateurs principaux désactivé une ou 2 fois…

Autre bug, pas moyen d’ajouter une application dans sécurité, il me propose un user et un mot de passe (ou le QRcode), mais je ne pas valider mon choix !

Je me demande si je dois laisser tout de même grader la ligne retirée ??
0 => 'localhost'

Je tiens à dire que je me suis perdu ! j’ai remis comme avant, les paramètres par défaut fonctionnent pour nginx ! Par contre sur une instance installée dans un sous path genre mondomaine.tld/nextcloud/ il y a un bug à corriger pour /.well-known/caldav que j’explique en-dessous.

1 Like

Je confirme, j’ai remis localhost dans l’array des trusted_domains et n’ai plus d’erreurs…
Il me semble que l’erreur devait être liés au liens cardav et caldav dans la conf nginx…

Bof !! vraiment bof… plus compliqué qu’il n’en a l’air…
Sur un autre serveur, je n’arrivais plus aussi a corrigé l’erreur de configuration .well-know… Au bout d’un moment la même erreur qu’ici et en effet, enlever localhost dans le array des trusted_domains semble la solution… Par contre impossible de corriger l’erreur de .well-know caldav et carddav. J’ai réinstallé le backup sur ce serveur en v28.0.6…

Pour ce que j’ai mis plus haut, ce n’est pas cohérent, j’ai remis aussi comme par défaut et en redémarrant nginx je n’ai pas d’erreurs… Je ne sais pas ce qui a bugué avec les .well-know, mais un comportement curieux avec cette 29…

Merci pour la solution de la ligne localhost, je n’ai plus l’erreur concernant l’exposition des fichiers, par contre j’ai toujours l’avertissement sur le /.well-known

J’ai regardé la configuration, mais j’ai l’impression que j’ai déjà celle proposée avec le / de fin sur :

location /.well-known/carddav {
    return 301 https://nextcloud.domaine.tld/remote.php/dav/;
}

location /.well-known/caldav {
    return 301 https://nextcloud.domaine.tld/remote.php/dav/;
}

Si jamais vous avez d’autres idées, merci !

Bonjour ,

Merci pour l’astuce par contre j’ai laissé:

1 => 'nextcloud.domaine.ndd',

Est ce qu’il faut mettre un 0 ou le 1 peut suffire ?
J’ai suivi bêtement la manœuvre mais je suis preneur d’une explicaton :grin:

Pour l’histoire du
/.well-known
Dans quel fichier je peux modifier ça ?

Bonjour,

dans /etc/nginx/conf.d/ton.domaine.tld/nextcloud.conf si je ne m’abuse.

Salut,

Pour le soucis du .well-know, si par hasard c’est le même soucis que j’ai rencontré pour le failed on: /.well-known/caldav, j’ai fini par trouvé le bug lié à Netxcloud.

Quand l’application est dans un sous-path moindomaine.tld/nextcloud/ il y a un bug car caldav va chercher le root path du domaine…

Du coup j’ai trouvé quelqu’un qui propose un patch…

Éditer le fichier /var/www/nextcloud/apps/settings/lib/SetupChecks/CheckServerResponseTrait.php pour changer la ligne 64

 60         protected function getTestUrls(string $url): array {
 61                 $hosts = $this->config->getSystemValue('trusted_domains', []);
 62                 $cliUrl = $this->config->getSystemValue('overwrite.cli.url', '');
 63                 if ($cliUrl !== '') {
 64                         $hosts[] =  $cliUrl;
 65                 }

avec :

 60         protected function getTestUrls(string $url): array {
 61                 $hosts = $this->config->getSystemValue('trusted_domains', []);
 62                 $cliUrl = $this->config->getSystemValue('overwrite.cli.url', '');
 63                 if ($cliUrl !== '') {
 64                         $hosts[] = rtrim(str_replace($this->urlGenerator->getWebroot(), '', $cliUrl), '/');
 65                 }

j’ai mis la solution ici

1 Like