Bonsoir !
Si mon problème d’accès via le nom de domaine a été résolu (voir mon 1er topic d’hier:) j’ai encore besoin de vous pour m’aider à finir l’installation de nextcloud.
Mais d’abord les infos essentielles !
Mon serveur YunoHost
Matériel: Raspberry Pi à la maison
Version de YunoHost: 3.6.5.3
J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran |
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Description du problème
Objectif : augmenter l’espace disponible pour nextcloud via l’ajout du HDD.
Problème : J’ai suivi pas à pas les indications données ici pour monter le HDD (sans problème) et ici pour qu’il soit accessible via Nextcloud (autant en cas A qu’en cas B). Tout se déroule bien lors de l’installation mais lors du scan du nouveau répertoire par Nextcloud j’obtiens “Your data directory is readable by other users
Please change the permissions to 0770 so that the directory cannot be listed by other users.”
Lorsque j’essaie d’accéder à Nextcloud j’ai droit à la même chose en plus poli :
Votre répertoire est lisible par les autres utilisateurs. Veuillez changer les permissions du répertoire en mode 0770 afin que son contenu ne puisse pas être listé par les autres utilisateurs.
Tentative de résolution du problème : J’ai bien essayé (naïvement, je suis néophyte en info) un "
chmod 775 -R /media/stockage" mais bon j’ai pas trop voulu insister non plus. Ces histoires de permission me semblent trop importantes d’un point de vue sécurité pour trop jouer avec le feu.
Bref, un p’tit coup de main ca serait pas refus ! Merci !
Bonsoir,
Si tu as bien suivi les deux tutoriels, je suppose que tu as un disque formaté en ext4, et qu’il est monté dans un répertoire appartenant à nextcloud ?
Si c’est bien le cas, alors un chmod 770 -R /media/stockage ne fera pas de mal et contentera Nextcloud. 
@tituspijean Non le disque dur n’est pas en ext4 mais en ntfs. J’ai ajouté le paquet ntfs-3g pour pouvoir l’utiliser avec debian.
Pour le chmod 770 malheureusement ca ne fonctionne pas. J’ai toujours le même message “Your data directory is readable by other users”
Oui en effet, dans le cas d’un disque en NTFS il faut changer le fstab. Dans mon cas, j’ai quelque chose du genre :
UUID=yyy /media/stockage ntfs-3g defaults,uid=999,gid=996,dmask=007,fmask=117,nofail 0 0
uid et gid sont les identifiants de mon utilisateur nextcloud. Tu peux les obtenir en faisant id nextcloud.
dmask à 007 va donner des répertoires avec les permissions 770.
fmask à 117 va donner des fichiers avec les permissions 660.
Après modification, teste la nouvelle configuration en dé/remontant le disque. 
Je viens de modifier mon fstab en “UUID=“40D0ECEDD0ECE9DC” /media/stockage ntfs defaults, uid=999, gid=996, dmask=007, fmask=117,nofail 0 0”
(Après id nextcloud j’ai les mêmes identifiants)
J’obtiens toujours le même message 
Essaie de redémarrer nginx pour qu’il se rende compte que le montage a changé: service nginx restart
Je viens de tenter le restart (et j’avais carrément fait un reboot juste avant). J’ai toujours le même message.
Bon, reprenons depuis le début
En utilisant les balises ```bla bla bla```, peux-tu indiquer ce que rendent:
blkidls -la /media- et le contenu de
/etc/fstab ?
Peux-tu confirmer que ton utilisateur Nextcloud est bien nextcloud ? Il aurait pu passer à nextcloud__2 par exemple si tu as installé l’app deux fois.
Voici les résultats des commandes :
- blkid
/dev/mmcblk0p1: LABEL=“boot” UUID=“8740-FD43” TYPE=“vfat” PARTUUID=“57d9db6d-01”
/dev/mmcblk0p2: LABEL=“rootfs” UUID=“de4a7c14-4fec-4c96-b27a-efd21fb63bc8” TYPE=“ext4” PARTUUID=“57d9db6d-02”
/dev/mmcblk0: PTUUID=“57d9db6d” PTTYPE=“dos”
/dev/sda1: LABEL=“EFI” UUID=“67E3-17ED” TYPE=“vfat” PARTLABEL=“EFI System Partition” PARTUUID=“76c0bd1f-d907-43e2-b4c8-0b37ce4a56bd”
/dev/sda2: LABEL=“Nouveau nom” UUID=“40D0ECEDD0ECE9DC” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“8ba23ab7-576b-4fa5-9446-f734e1914479”
- ls -la /media
total 12
drwxr-xr-x 3 root root 4096 Jan 5 22:13 .
drwxr-xr-x 22 root root 4096 Jan 5 21:11 …
drwxrwxrwx 1 root root 4096 Jan 6 19:00 stockage
- Contenu de fstab
Blockquote
proc /proc proc defaults 0 0
PARTUUID=57d9db6d-01 /boot vfat defaults 0 2
PARTUUID=57d9db6d-02 / ext4 defaults,noatime 0 1
'# a swapfile is not a swap partition, no line here
'# use dphys-swapfile swap[on|off] for that
UUID=“40D0ECEDD0ECE9DC” /media/stockage ntfs defaults, uid=999, gid=996, dmask=007, fmask=117,nofail 0 0
Pour l’utilisateur, je ne sais pas où trouver l’info. En tout cas, l’id que l’on trouve dans la partie application de l’interface web de Yunohost est bien “nextcloud”
P.s : je ne suis pas sûr d’avoir utilisé les bonnes balises. S’il y a besoin de modifier hésite pas à me le demander 
Pas de soucis pour les balises, c’est tout à fait lisible.
Comme tu le vois, ton dossier /media/stockage se retrouve appartenant à root avec les droits 777… ce qui veux dire que tes instructions sont pas bonnes.
Dans /etc/fstab, enlève les guillemets autour de l’UUID, et enlève tous les espaces après les virgules. Il faut aussi indiquer ntfs-3g pour être sûrs que le bon système gère le disque. Ajoute aussi un umask=007 au cas-où:
UUID=40D0ECEDD0ECE9DC /media/stockage ntfs-3g defaults,uid=999,gid=996,umask=007,dmask=007,fmask=117,nofail 0 0
Démonte, et remonte le dossier, et redémarre le service nginx.
Alors je sais pas comme on démonte un dossier, du coup j’ai reboot haha.
Quoiqu’il en soit ca marche ! Hallelujah ! Merci beaucoup !
Enfin, presque. Y’a un endroit où ca bloque encore. Quand je vais dans les parametres de nextcloud il me dit
La tâche cron n’a pu s’exécuter via CLI. Ces erreurs techniques sont apparues :
Your data directory is readable by other users Please change the permissions to 0770 so that the directory cannot be listed by other users.
Je sais pas si c’est le lieu pour les problèmes liés au fonctionnement même des apps mais comme ca semble, à mes yeux de néophyte, être la suite du problème initial je demande quand même.
Quoiqu’il en soit je peux me connecter à nextcloud et ca c’est super chouette ! Merci beaucoup !
1 Like
C’est tout à fait le lieu, pas de problème.
Pour démonter ton dossier: umount /media/stockage et mount /media/stockage pour le remonter.
Je soupçonne que le message à propos de la tâche cron date d’avant la résolution du problème. Peux-tu tenter de lancer sudo -u nextcloud php -f /var/www/nextcloud/cron.php ? C’est la commande que cron lance toutes les 15 minutes. Si elle ne grogne pas, c’est que tout va bien.
Je viens de relancer nextcloud pour voir si le message d’erreur apparaissait toujours. Et non ! Il a disparu, c’était donc bien que la tache cron datait d’avant la résolution du problème.
J’ai lancé la commande tout de même (on sait jamais) et rien ne s’est passé. Je suppose que ca correspond à ne pas grogner haha !
Sauf contre indication de ta part, je pense que je peux passer le topic en résolu.
Encore merci ! Me voilà avec un nextcloud fonctionnel, hallelujah !
1 Like
Content de l’apprendre. Pense à marquer ce fil comme résolu, ça aidera les suivants.
Profite bien de ton Nextcloud !
En fait c’était un faux espoir. L’upload de fichier, qui fonctionnait avant mon ambition de rajouter un hdd externe, ne fonctionne plus.
La barre qui indique l’upload reste bloquée sur “quelques secondes”. ô rage, ô desepoir 
Cafetiere…
Juste une petite info… Moi j’ai installé YunoHost sur un RaspBerry… mais surtout sur un disque dur externe (en fait un SSD)… Je boote direct mon YnoHost sur le SSD externe…
C’est possible, mais il faut faire l’installation manuelle… et c’est pas très compliqué… une commande qui fait tout!
JM
Ps: Une SSD externe c’est plus sûr qu’une carte SD… de plus le SSD est pourvu de la technologie SMART pour contrôler le vieillissement!
J’aimerais bien avoir un sdd sous la main pour pouvoir faire ca
Malheureusement j’ai qu’un disque dur externe de derrière les fagots et comme un raspberry c’est pas déjà un foudre de guerre j’ai peur de lenteur en mettant le système d’exploitation sur le hdd.
Mais j’avoue que ca aurait été une bonne solution ! Merci (pour la deuxième fois en 2 jours) @pti-jean !
Là je donne ma langue au chat. Je ne vois pas quel pourrait être le problème. Au cas-où, peux-tu ouvrir la console de ton navigateur (F12 > console) avant l’upload pour voir s’il y a une erreur qui ressort ?
Ça vaudrait peut-être le coup d’essayer sur un HDD… Par-ce que dans mon cas il s’agit un Raspberry PI 3 B+ … que le SSD est connecté sur de l’USB2… et que donc je ne profite pas de la vitesse du SSD, car je suis limité par l’USB2…
Donc HDD ou SSD, c’est l’USB2 qui fixe la limite.
À mois que tu aies sous la main un Raspberry PI 4… là, je crois que cela voudrait vraiment le coup un SSD!
JM