[Résolu] Problème avec Nextcloud (et nginx ?) : mise à jour impossible et 404 Not Found


Bonjour !

Matériel: Raspberry pi 3B+
Version de YunoHost: YunoHost (stable) (ce qui est affiché en bas de l’interface admin, je viens de mettre à jour le système)
J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran (si besoin)
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : J’ai installé beaucoup d’apps, pour finalement n’en conserver que quelques unes.

Description du problème

J’ai essayé de mettre à jour mes applications, et il apparaît impossible de mettre à jour Nextcloud (pour être plus précis, il bloque aux backups. Voici le log de l’erreur : https://paste.yunohost.org/raw/onodoxosot

De plus, il ne m’est plus possible d’accéder à Nextcloud et j’ai diverses problèmes de certificat qui ont poppé en mode random (sans aucune modification de ma conf dns et avec un certif Let’s Encrypt, je pouvais plus accéder à mon serveur, mais j’ai pu en passant par le réseau local, et j’ai dû revenir à domainname.ynh.fr comme domaine par défaut).

A l’url de Nextcloud, j’ai une erreur 404 de Nginx. Et de fait, je soupçonne de fait nginx d’être responsable direct de mes problèmes (je me dis qu’il y a peut être eu des installs/désinstalls incomplètes qui ont fait perdre les pédales à la conf nginx).


Je n’ai pas utilisé hastebin et le bouton Téléversement car il semblait téléversé tout le temps le même fichier, donc je me demande si il est pas cassé.

Je n’ai mis que les deux logs de nginx qui me semblaient principaux mais je peux tous les mettre si besoin.

Plein de santé et de bonnes choses à quiconque pourra m’aider : je n’y connais rien à nginx (d’ailleurs, si des gens ont des liens sympathiques pour le découvrir, je suis preneur :slight_smile: )

Solution Diagnostic de carte SD corrompue. Réparer avec un fsck -sy /dev/le_periph à partir d’un autre linux. Conseil : faire une bakcup tous les mois du fiat que c’est une SD card.

For an unknown reason, your php config for nextcloud is not at the right place (/etc/php/7.0/fpm/pool.d/nextcloud.conf)

If you have a backup of nextcloud, you should either restore it or just get back the php config.

Thanks for your answer. It’s in fact impossible for me to restore : that fails. It seems there is a big problem in my installation so i think i’ll reinstall tomorrow, to get a clean installation.

I see “”/var/www/nextcloud/index.php" failed (13: Permission denied)" in your log, did you do anything special in your server in CLI ?
To don’t have the permission on this file is hardly possible.
(edit, a little negation on the previous line, and everything makes more sense !)

Did you install apps that had a big warning telling not to do it ?

Not at all, I’ve always used apps in the catalog (lvl 6 at least). But now I get many certificate errors and nginx errors. And some other random errors that make thinking me the system is broken in many places for no-known reasons :frowning:

Oh a raspi !

I think you should go first for a check disk of your SD card.

1 Like

It was new when I installed Yunohost, and I’ve tested it with f3probe to check the class 10 before using it. With which tool may I check the SD Card “safeness” (don’t know the english word) ?

Just check it with your usual tool, gparted, partitionmanager and any other you like.
But, it would be safe to make a copy before if you don’t already have one.

I feel like your SD card may have some trouble. But probably just some inconsistencies in the file system.

I’ve checked with f3probe which didn’t find errors (anyway, it’s not its goal). After i’ve run fsck -sy /dev/mmcblk1p2 (the rootfs part of Yunohost), and that’s revealed many problems (so many that I can’t copy from my terminal to put it in a paster). The last message part is

rootfs: ***** FILE SYSTEM WAS MODIFIED *****
rootfs: 105327/1877344 files (0.5% non-contiguous), 1393770/7779456 blocks

I’ve started again the same command and got

fsck from util-linux 2.35.1
e2fsck 1.45.6 (20-Mar-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 105327/1877344 files (0.5% non-contiguous), 1393770/7779456 blocks

Do you think it’s ok ? Or should I change my SD card ?

[I’ve never checked disk integrity on linux till today]

But you do not check the SD card from the system that run on.
You have to turn off your Rpi, remove the sd card, and check it from another computer.

Most of the time, that’s only small glitches that can be repaired easily. But If do not that often, you may loose some files in the process…

Personally, I recommend a reboot at least once a month to allow the boot process to check the disk.

That commands come from my pc on ArchLinux ? Is it ok ? (i didn’t execute them from my raspi)

Oh ok, that’s fine then, I thought you were doing it directly from your Rpi !

If the second command is ok, then you SD card id fine.
But, if the first one gave you a lot of error, you may have lost some files in the process.

Have a look to the root of the sd card, you can find the residues.
Otherwise, you can try to put it back.

If you have a backup of your whole YunoHost, I suggest to reinstall and restore the backup.

I didn’t so use my YunoHost server till here, and I’ve already backed up the files in Nextcloud I wanted to keep. So i was thinking about reformat, reinstall YunoHost, and then reinstall the apps I want.

I want to mean : i don’t need to restore. So what I want to do seems ok, too ?

(ok, my question looks quite stupid, but I prefer controlling this time :3 )

Yes in that case you can totally reinstall directly.
But, as you’re running on a SD card, I would strongly recommend you to have recurrent backup somewhere else.

Ok, I’ll do this.

Thanks for your help :slight_smile:

It seems that my public IP has changed (i don’t know when and why or how), that could explain some of my problems, but not at all all of these.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.