Donner de la place à NextCloud sur Raspberry Pi

C’est à cet endroit que je cale. Quand je lance la commande, il me demande le mot de passe de l’utilisateur nextcloud. Je ne me souviens pas avoir défini un tel mot de passe et je n’ai aucune idée de ce qu’il peut être, vu que ce n’est même pas celui que j’utilise pour me connecter à nextcloud. Y a-t-il un moyen de le connaître ?

Tu devrait aussi pouvoir créer ce fichier en tant que root/admin normalement. Il faut juste que le fichier ait les bonnes permissions à la fin (par exemple tu peux faire un chown nextcloud:nextcloud lenomdufichier pour donner les permissions à nextcloud sur le fichier)

Voilà, c’est fait.

Maintenant, quand j’essaye d’y accéder via le web, j’ai «erreur interne du serveur» et mes outils de synchronisation me disent «server replied: forbidden» et «opération annulée».

J’ai réessayé en suivant ccrupuleusement la marche à suivre, avec le même résultat, à ceci près que cette fois, mon outil de synchro me dit «internal server error».

Est-ce que tu peux regarder ce qu’il se passe avec un tail -n 50 -f /var/log/nginx/*.log (cette commande continuera à tourner et afficher les nouvelles lignes dans le log jusqu’à ce que tu la quittes avec Ctrl+C) et que tu accèdes à la page qui fait provoque une erreur en parralèle ?

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 :frowning:

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” :smile:.
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!