Mount-Problem nach Update auf 8.3.1

A

andr3

New Member
Dec 15, 2024
6
1
3
Nabend! Vielleicht kann mir jemand helfen, bevor meine Frau mich tötet! :eek::rolleyes:

Seit dem Update auf 8.3.1 ist unsere Nextcloud mit ihren Dokumenten nicht mehr erreichbar.
Bzw. konnte Proxmox nach dem Update erst gar nicht mehr booten.
Nach dem löschen dieser Zeile aus der fstab konnte normal hochgefahren werden:

/dev/sda1 /media/disk ext4 uid=1005,gid=1005 0 1

Nur hat damit die Nextcloud ihr medium verloren.
Wenn ich diese Zeile wieder eintrage und das ganze vor einem Neustart vorsichtshalber mit mount -a teste, wird mir diese Meldung hier angezeigt:

/media/disk: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

Wer hat einen Lösungsansatz für mich? Braucht ihr mehr Infos? HELP & TAUSEN DANK!
 
Last edited:
Welche fstab ist das, vom Proxmox-Host oder der Nextcloud VM? Gibt es dort /dev/sda noch (lsblk ausführen) und eine Partition sda1 (fdisk -l /dev/sda)?
 
Es ist die fstab vom Proxmox-Host. Sowohl /dev/sda als auch die Partition sda1 sind vorhanden und werden mir angezeigt.
 
Last edited:
Du bist dir auch sicher, dass sda die richtige Disk ist? Die Benamung sda ist nicht konsistent und kann theoretisch nach jedem Reboot anders sein.

Mach mal lsblk -f dann wird das FS der partitionen mit angezeigt.
 
Also @maxim.webster mit dem Befehl fdisk -l /dev/sda wird mir das hier ausgespuckt:
Disk /dev/sda: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model:
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 07E52103-9E30-4AC1-8936-51246492965F

Device Start End Sectors Size Type
/dev/sda1 2048 11721043967 11721041920 5.5T Linux filesystem

@Falk R. mit lsblk -f das hier:
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
└─sda1 ext4 1.0 d52bef24-6261-4dd7-8f67-7d56d1011d5e
 
Dann befürchte ich bad superblock on /dev/sda1, ist dein Problem.
Lass die Disk mal checken und ich hoffe du hast ein Backup, bevor du eine Reparatur laufen lässt.
Keine Reparatur garantiert dir, deine Daten heile zurück zu bekommen.
In der Regel passiert soetwas nicht durch updates, sondern unsauberem ausschalten des Servers.
 
Ach du Schreck :(
Nach dem Update gab es einen Neustart. Eventuell war das dann der Übeltäter!

Gibt’s Befehle zum checken der Platte?

Wie lässt sich jetzt wohl noch was retten?
 
Dann ist dein pve auf /dev/nvme0 installiert (sda ist ansonsten eigentlich allermeistens die Systemplatte) ?
Du kannst das ext4 mit anderem Superblock (als dem default) mounten (-> googlen), ggf. erstmal Daten davon sichern und danach ein fsck laufen lassen, um diesen defekten Block wieder neu schreiben zu lassen.
 
Hi,
andr3 said:
Nur hat damit die Nextcloud ihr medium verloren.
Wenn ich diese Zeile wieder eintrage und das ganze vor einem Neustart vorsichtshalber mit mount -a teste, wird mir diese Meldung hier angezeigt:

/media/disk: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

Wer hat einen Lösungsansatz für mich? Braucht ihr mehr Infos? HELP & TAUSEN DANK!
Click to expand...
weil es sonst noch nicht vorgeschlagen wurde (außer von der Fehlermeldung selbst ;)), bitte auch dmesg bzw. System-Logs kontrollieren, da steht vielleicht etwas mehr zum Fehler.
 
  • Like
Reactions: Falk R.
Wann immer ich einer solchen Bad superblcock Meldung begegnet bin, war die einzige Möglichkeit meine Disk zu retten:
fsck.mode=force fsck.repair=yes in GRUB beim Start des Systems mit anzugeben. Ich habe noch keine andere Anleitung gefunden, die einen bad superblock Fehler beheben konnte.
 
Es ist aber nicht die OS disk, sondern eine Option disk. Wie gesagt fsck "sollte den" Superblock mithilfe der Duplikate wieder herstellen können ... kann aber auch schiefgehen.
 
Mithilfe eines Duplikates konnte ich noch nie den Superblock wiederherstellen. Möglich, dass ich nie die richtige Anleitung gefunden habe. Man steht ja in solchen Situationen schon sehr unter Stress. Aber ich habe damit sowohl root also auch Festplatten mit home darauf gerettet. Im Jahre 2018 hatte ich das sogar drei Monate lang wöchentlich gebraucht, weil ich aus unbekannten Gründen auf meinem Home wöchentlich einen Superblock Fehler hatte. Wie man das mit der Option Disk machen müsste weiss ich leider nicht.
 
LaWLi said:
Wann immer ich einer solchen Bad superblcock Meldung begegnet bin, war die einzige Möglichkeit meine Disk zu retten:
fsck.mode=force fsck.repair=yes in GRUB beim Start des Systems mit anzugeben. Ich habe noch keine andere Anleitung gefunden, die einen bad superblock Fehler beheben konnte.
Click to expand...
Es ist auch noch nicht klar, ob es da wirklich einen bad superblock gibt. Die Fehlermeldung erwähnt das nur als eine Möglichkeit. Dazu muss erst mal im Log nachgeschaut werden, wo hoffentlich die präzisere Fehlermeldung steht.
 
fsck.ext4 /dev/sda1 gibt folgendes aus:

e2fsck 1.47.0 (5-Feb-2023)
/dev/sda1: clean, 125988/183144448 files, 16493263/1465130240 blocks

@fiona Wie kann ich die benötigten Log/Informationen ziehen? Vielleicht sagen die euch ja direkt was! (EDIT: sorry, wird ja oben von dir schon erwähnt! Mache ich gleich mal!)

Kurz nochmal zu meinem Setup, damit keine Missverständnisse zu meiner Situation auftauchen: Proxmox läuft auf einem NUC mit interner Festplatte (M.2 NVMe). Am NUC hängt eine Externe HDD, die rein für die Nextcloud als Speicherplatz dient. Auf dieser befinden sich die aktuell nicht erreichbaren Daten.

Was mich so verwirrt: Proxmox konnte die letzten Monate problemlos booten, selbst wenn diese externe Festplatte nicht angeschlossen oder ausgeschaltet war. Natürlich hat Nextcloud selbst dann auch "gezickt" aber da war der Grund ja klar. Nun aber diese Probleme mit eingeschalteter und angeschlossener Festplatte nach dem Update von Proxmox...
 
Last edited:
ENDLICH!
Tausend Dank an @fiona ! Letzendlich war ich zu blöd, an die Logs zu denken. Habe sie mir mal ausspucken lassen und nach ein bisschen Google-Arbeit zu den ausgespuckten Fehlern, bin ich auf eine Lese-Schreib-Rechte-Problematik gestoßen.

Mit chown -R 33:33 /media/disk/* konnte ich die entsprechenden Rechte erneut vergeben und nun klappt ALLES wieder! :eek:
 
  • Like
Reactions: waltar
Wir haben das Problem auch wiederholt mit dem Bad Superblock; die Schreibrechte können wir nicht ändern, weil das System denkt dass noch eine andere Externe Platte gemountet ist als physisch dran hängt.

Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/namespace: 400 Bad Request: [client [::ffff:192.168.99.11]:51446] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/rrd?timeframe=hour&cf=AVERAGE: 400 Bad Request: [client [::ffff:192.168.99.11]:51652] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status: 400 Bad Request: [client [::ffff:192.168.99.11]:51651] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status/?verbose=true: 400 Bad Request: [client [::ffff:192.168.99.11]:51446] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status/?verbose=true: 400 Bad Request: [client [::ffff:192.168.99.11]:51651] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:21 pbs1 kernel: XFS (sdc1): Filesystem has duplicate UUID e0cc4538-be88-40a4-8a35-d0287abfa7a3 - can't mount
Feb 03 08:37:21 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status: 400 Bad Request: [client [::ffff:192.168.99.11]:51446] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:21 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status/?verbose=true: 400 Bad Request: [client [::ffff:192.168.99.11]:51651] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:23 pbs1 kernel: DMAR: DRHD: handling fault status reg 302
Feb 03 08:37:23 pbs1 kernel: DMAR: [DMA Write NO_PASID] Request device [04:00.0] fault addr 0x791f4000 [fault reason 0x05] PTE Write access is not set
Feb 03 08:37:28 pbs1 kernel: DMAR: DRHD: handling fault status reg 402
Feb 03 08:37:28 pbs1 kernel: DMAR: [DMA Write NO_PASID] Request device [04:00.0] fault addr 0x791f4000 [fault reason 0x05] PTE Write access is not set

Es hilft dann ein Serverneustart und dann geht es wieder.
 
Hi,
f.sennj said:
Wir haben das Problem auch wiederholt mit dem Bad Superblock; die Schreibrechte können wir nicht ändern, weil das System denkt dass noch eine andere Externe Platte gemountet ist als physisch dran hängt.

Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/namespace: 400 Bad Request: [client [::ffff:192.168.99.11]:51446] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/rrd?timeframe=hour&cf=AVERAGE: 400 Bad Request: [client [::ffff:192.168.99.11]:51652] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status: 400 Bad Request: [client [::ffff:192.168.99.11]:51651] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status/?verbose=true: 400 Bad Request: [client [::ffff:192.168.99.11]:51446] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:20 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status/?verbose=true: 400 Bad Request: [client [::ffff:192.168.99.11]:51651] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:21 pbs1 kernel: XFS (sdc1): Filesystem has duplicate UUID e0cc4538-be88-40a4-8a35-d0287abfa7a3 - can't mount
Feb 03 08:37:21 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status: 400 Bad Request: [client [::ffff:192.168.99.11]:51446] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:21 pbs1 proxmox-backup-proxy[1766]: GET /api2/json/admin/datastore/EXT2-22TB/status/?verbose=true: 400 Bad Request: [client [::ffff:192.168.99.11]:51651] datastore 'EXT2-22TB' is not mounted
Feb 03 08:37:23 pbs1 kernel: DMAR: DRHD: handling fault status reg 302
Feb 03 08:37:23 pbs1 kernel: DMAR: [DMA Write NO_PASID] Request device [04:00.0] fault addr 0x791f4000 [fault reason 0x05] PTE Write access is not set
Feb 03 08:37:28 pbs1 kernel: DMAR: DRHD: handling fault status reg 402
Feb 03 08:37:28 pbs1 kernel: DMAR: [DMA Write NO_PASID] Request device [04:00.0] fault addr 0x791f4000 [fault reason 0x05] PTE Write access is not set

Es hilft dann ein Serverneustart und dann geht es wieder.
Click to expand...
bitte mal den ganzen Log posten, sowie die Datastore-Konfiguration cat /etc/proxmox-backup/datastore.cfg als auch Ausgabe von lsblk und mount. Bitte auch mal mit smartctl einen Health-Check machen und ein fsck vom Dateisystem.
 
mache ich wenn es das nächste mal auftritt, hatten schon neugestartet. Wiegesagt ich glaub eich nicht dass die Disk selbst betroffen ist, sonst würde ja ein simpler neustart nicht helfen.
 
f.sennj said:
Feb 03 08:37:21 pbs1 kernel: XFS (sdc1): Filesystem has duplicate UUID e0cc4538-be88-40a4-8a35-d0287abfa7a3 - can't mount
Click to expand...
Wie geht das denn ?!? Mal "xfs_repair /dev/sdc1" auf abgemountetes device laufen lassen !
 
You must log in or register to reply here.
Top Bottom