En fait j’ai trouvé, il suffisait de faire un «chown -R nextcloud:nextcloud» sur le dossier désiré. ça a tout débloqué.
Un an plus tard …
Pour les possesseurs de raspberry pi comme moi, plutôt que déplacer simplement le répertoire data de Nextcloud sur un disque externe, la méthode qui consiste à tout déplacer sauf le “boot” semble plus intéressante.
Ainsi vous aurez non seulement de la place pour les données Nextcloud mais également pour toutes les autres applications Yunohost que vous désirez installer dans l’avenir.
Merci à @zain pour ce lien: http://www.planet-libre.org/?post_id=21555
Si vous voulez lire le sujet sur le forum, c’est par ici: Rajouter de l’espace stockage yunohost
3 Likes
De rien!
Et merci @beer2beer de partager dans les bon topics.
L’artice était plus agréable à lire directement sur le site de @MaxKoder (max-koder;fr), mais comme je le disait ça ne fonctionne plus depuis un moment.
J’espère que Max va bien, peut-être certains sur le forum le connaisse mieux.
Aussi, une remarque sur cette méthode de disque externe: de temps à autre, mon serveur n’est plus de tout accessible, même en ssh. je dois redémarrer le pi en débranchant rebranchant.
Je me suis dit, c’est une hypothèse, que ça pourrait venir du disque externe qui se met en veille tout seul, et vu que la carte sd n’est plus active pour le réveiller, y’a plus rien qui marche.
Le disque est un 2,5’ auto-alimenté dans un boitier usb 2.0 avec donc sa petite interface sata-usb (j’ai mis moi-même le disque 2,5’ dans le boitier vide, je précise!).
Donc question: Si cela s’avère exact, est-ce Debian qui met en veille le disque? ou lui-même par sa propre interface usb? auquel cas il faudrait modifier le hardware…
Enfin voilà je lance l’idée, si vous connaissez un autre sujet qui traite un peut de la même chose n’hésitez pas à partager, et si le coeur vous en dis, testez!!!
Bonne soirée à tous
1 Like
Étrange en effet, je n’ai pas vraiment d’idée d’où peut venir ton problème mais ta piste semble cohérente.
Pour ma part j’ai un disque dur 2.5" auto-alimenté également branché sur mon raspberry pi, mais j’ai suivi un autre tuto pour déplacer seulement la partition /home et je ne rencontre aucun problème de ce type.
Je mets ici le lien vers le tuto que j’ai suivi, ça peut en intéresser certains: https://www.maketecheasier.com/move-home-folder-ubuntu/
Sinon, je résume ci-dessous la procédure en français (si d’aventure le lien venait a ne plus fonctionner un jour):
–
Déplacez /home sur un disque dur externe:
/!\ Remarque mon disque externe était déjà formaté en ext4 au préalable.
==> Ouvrir un terminal et tapez ce qui suit:
sudo blkid
==> affiche les infos du disque dur externe
sudo nano /etc/fstab
==> ajouter la ligne suivante au fichier (remplacez les “x” par vos informations"
UUID=xxxxxx-xxxxxx-xxxxxx-xxxxx /media/home ext4 nodev,nosuid 0 2
==> enregistrer, fermer
sudo mkdir /media/home
sudo mount -a
sudo rsync -aXS /home/. /media/home/.
cd /
sudo mv /home /home_backup
sudo mkdir /home
sudo nano /etc/fstab
==> supprimer /media de la ligne, ça donne ça:
UUID=xxxxxx-xxxxxx-xxxxxx-xxxxx /home ext4 nodev,nosuid 0 2
sudo mount -a
sudo rm -rf /home_backup
==> Une fois terminé redémarrez votre raspberry pi pour prendre en compte les modifications
sudo reboot
Voilà, normalement tout s’est bien passé et votre partition /home se trouve maintenant sur votre disque dur externe.
1 Like
Oui. Intéressant aussi.
Si l’espèce de théorie que j’avance n’est pas trop fumeuse, on peut éventuellement avancer deux choses:
Sur ton montage le système yunohost est sur la carte sd du pi et est là pour activer le disque externe au besoin.
Max Koder quant à lui, s’il n’a pas rencontrer le problème, c’est peut être parce qu’il s’auto-héberge complètement, ses mails, son site, son blog, son cloud et j’en passe; du coup son disque connait suffisamment de trafic pour ne pas avoir le temps de tomber en veille.
Enfin bon pour tout ça ce n’est que spéculations et il est bien possible que je soit bien à côté de la plaque!!
Mais en tout cas ce qui me plait vraiment dans la méthode de max c’est qu’on est à peu près sûr de n’avoir aucun problème de droit, permission, exécution, installation, utilisation, accès, etc… vu que c’est tout le système qu’on installe sur le disque et non une partie.
Bonne journée à tous!
1 Like
Une autre réflexion:
Nous pourrions imaginer appliquer la méthode de @MaxKoder dès la fin de l’installation, avant même la post-install.
Question/avantages/inconvénients:
Ca ne change rien, on peut le faire et donc on est pas plus avancé;
Ou alors ça met le bordel quelque part et donc il ne faut surtout pas le faire.
A tester alors!! Je devrai pour voir faire ça lundi ou mardi, après ça mon serveur entrera en production donc pas plus de test.
Bon week-end à tous!
1 Like
Ça ne fonctionne pas pour moi. Même après un chown (en nextcloud:nextcloud ou nextcloud:owncloud) pour tout le dossier copié.
Si je change le chemin dans config.php, j’ai ça :
Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.
Sur une page sans rien d’autre que le texte (pas de CSS, etc).
coucou @Lapineige, malheureusement je n’utilise plus cette méthode car elle posait plusieurs problèmes.
-
Le premier étant que si Nextcloud modifie ou écrase l’emplacement ou le contenu des fichiers config lors de mises a jour ou change sa structure cela pourrait causer des problèmes de mises a jour dans le futur.
-
La seconde raison étant que je voulais utiliser l’espace de mon disque externe pour pouvoir également installer d’autres applications Yunohost que seulement Nextcloud.
J’ai donc suivi la méthode qui consiste a déplacer/auto-monter la partition /home sur le disque dur externe afin d’en profiter pleinement, comme décrit dans le méssage du 7 févr. (marqué comme solution).
Je suis navré mais je ne comprends pas d’où provient le problème au vu de ton message 
1 Like
C’est prévu, mais pas de suite de suite, je ne veux pas faire ça sans une copie totale de la carte SD et du disque dur, pour éviter de tout péter. Ou plutôt, pour avoir une option “ctrl+z” 
.
Et je vais éviter (c’est possible de le faire d’ailleurs ?) de faire ça “à chaud”.
Donc en attendant ça m’arrangerait bien.
Rechanger la config en cas de mise à jour, si c’est juste remettre la ligne, je peux gérer.
Le tout est de savoir pourquoi la moindre modif’ ne lui plaît pas… un autre fichier de config à modifier ?
edit : alors après test, j’ai changé /home/yunohost.app/nextcloud en /home/yunohost.app/nextcloud2, et modifié le fichier de config en conséquence.
Ça marche.
Y’a donc autre chose…
Ceci dit, il a mouliné un certain temps ensuite, avec un accès disque prolongé. Je ne sais pas si c’est lié.
1 Like
Ah, en refaisant la manip’, mais avec cp -a cette fois (au lieu de cp -R), ça a l’air de fonctionner.
Ça devait être un problème de droits, que je pensais avoir réglé pourtant.
Impressionnant ce que Nextcloud gagne en rapidité une fois les données sur le disque dur ! (10 fois plus rapide que la carte SD)
1 Like
Content pour toi @Lapineige , tu gères ^_<
Donc, @beer2beer , si je suis ta méthode du 7 février et déplace home, qu’est-il écrit ensuite sur la sd lors de l’utilisation de yunohost ?
Et il ne faut pas suivre la méthode du 6 février … ?
Hum, j’ai un nouveau problème, pas certain que ça soit lié mais on dirait : j’ai certain dossiers où il ne veut plus me laisser créer/modifier les fichiers.
La synchro fonctionne (et je peux éditer sur ma machine, c’est bien appliqué. Mais pas en ligne).
Salut @arnauld , moi personnellement j’ai suivi la méthode du 7 février.
Dans ce cas tout est écrit sur la carte SD sauf la partition /home qui elle est déplacée sur disque dur externe. Pour moi cette méthode a marché sans problème.
“system”: {
“disks”: {
“root”: “Mounted on /, 14.6GiB (11.0GiB free)”,
“mmcblk0p1”: “Mounted on /boot, 62.0MiB (41.1MiB free)”,
“sda1”: “Mounted on /home, 1.8TiB (1.2TiB free)”
Personnellement je n’ai pas testé la méthode du 6 février car dans le cas de @zain cela semblait provoquer une sorte de mise en veille de son disque (c’est une théorie qu’il a évoqué qu’il faudrait confirmer).
Dans le doute, j’ai décidé de suivre l’autre méthode donc.
Salut @beer2beer et à tous, j’ai réinstallé depuis, toujours en suivant la méthode de @MaxKoder, pour mettre en production, et aucun problème à signaler, tout fonctionne très bien.
1 Like
Merci @zain pour ton retour ^_< c’est bon a savoir!
Cela semble être un problème de droits si c’est uniquement certains dossiers/fichiers.
Je n’ai pas compris cette phrase, peux-tu être plus explicite 
“La synchro fonctionne (et je peux éditer sur ma machine, c’est bien appliqué. Mais pas en ligne).”
En ligne de commande ?
Oui j’aurai pu le faire avant, et en même temps ça demande souvent un peu de temps pour voir si des erreurs réapparaissent.
Je pense plutôt que j’ai été berné par mon inexpérience des serveurs. Je l’impression que le “problème” dont je parlais pouvait bien être un retour “dyndns dev null” avec mail associé, résolu bien sur en fixant l’ip et en commentant la ligne dans le /etc/cron.d.
Enfin, autre sujet!
1 Like
Merci en tout cas pour ton retour, cela permettra peut-être a d’autres personnes de s’en sortir s’ils rencontrent le même problème ^_<
Ah oui, une dernière chose à propos de la méthode de @MaxKoder, je me demandais plus haut (9 fév) s’il vaut mieux appliquer le déplacement complet avant ou après la post install.
Et bien c’est après, sinon ça plante.
Donc Install, post install, et enfin la méthode de @MaxKoder.
Cette méthode laisse entendre aussi qu’ensuite on peut tout déplacer un peu quand on veut, même avec des app installées et des données stockées, puisqu’on parle de déplacement de partitions entières.
1 Like