NEWS
Problems using influxDB on an external SSD
-
Mar 24 18:28:31 ioBroker usbmount[300]: /dev/sda does not contain a filesystem or disklabel Mar 24 18:28:31 ioBroker systemd-udevd[169]: Process '/usr/share/usbmount/usbmount add' failed with exit code 1. Mar 24 18:28:31 ioBroker systemd-udevd[159]: Process '/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev' failed with exit code 1.Da ist wohl auf dem Speichermedium /dev/sda was krumm.
Und dann schalte den Desktop-Mist (mit Remote-Desktop) aus. Server immer ohne GUI, per SSH-Zugang betreiben.@thomas-braun Kann ich noch etwas machen? Ich habe leider das Problem immer noch nicht gelöst.
-
@thomas-braun Kann ich noch etwas machen? Ich habe leider das Problem immer noch nicht gelöst.
Keine Ahnung. Mir ist immer noch nicht klar, wie das Dateisystem gemounted wird. Per automount?
-
Mar 24 18:28:31 ioBroker usbmount[300]: /dev/sda does not contain a filesystem or disklabel Mar 24 18:28:31 ioBroker systemd-udevd[169]: Process '/usr/share/usbmount/usbmount add' failed with exit code 1. Mar 24 18:28:31 ioBroker systemd-udevd[159]: Process '/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev' failed with exit code 1.Da ist wohl auf dem Speichermedium /dev/sda was krumm.
Und dann schalte den Desktop-Mist (mit Remote-Desktop) aus. Server immer ohne GUI, per SSH-Zugang betreiben.@thomas-braun sagte in Problems using influxDB on an external SSD:
dev/sda does not contain a filesystem or disklabel
bedeutet doch eher, das die Platte nicht korrekt formatiert ist
@Mathias2803 vllt hilft https://github.com/rbrito/usbmount/issues/24
umgestiegen von Proxmox auf Unraid
-
@thomas-braun sagte in Problems using influxDB on an external SSD:
dev/sda does not contain a filesystem or disklabel
bedeutet doch eher, das die Platte nicht korrekt formatiert ist
@Mathias2803 vllt hilft https://github.com/rbrito/usbmount/issues/24
Ja, hatte ich ja auch schon geschrieben.
-
Keine Ahnung. Mir ist immer noch nicht klar, wie das Dateisystem gemounted wird. Per automount?
Das mouten passiert durch "/etc/fstab" und dem Eintrag:
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw 0 2"
-
@thomas-braun sagte in Problems using influxDB on an external SSD:
dev/sda does not contain a filesystem or disklabel
bedeutet doch eher, das die Platte nicht korrekt formatiert ist
@Mathias2803 vllt hilft https://github.com/rbrito/usbmount/issues/24
@crunchip
Die Platte ist normal ansprechbar. Ich kann dort Dateien schreiben und lesen.Nachdem ich Datenbank von influxDB von der Sicherungskopie, die auch auf der externen Platte liegt, wieder hergestellt habe, läuft das Logging auch auf der externen Platte ohne Probleme.
Jedoch sobald ich das System neu starte mit "sudo reboot" ist wieder alles kaputt und ich muss wieder alles kompliziert herstellen. Also zuerst alle Systeme deaktivieren, dann die DB löschen, aus dem BackUp wieder herstellen und wieder alles neu starten...
Schlimm ist wenn das System aus anderen Gründen neu startet, ich kein aktuelles BackUp habe,... jedes Mal Daten Verlust...
-
Das mouten passiert durch "/etc/fstab" und dem Eintrag:
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw 0 2"
@mathias2803 sagte in Problems using influxDB on an external SSD:
nofail,rw
Das sind zu wenig Optionen.
Ich würde da wenigstens 'defaults' noch setzen, besser noch den richtigen User, der drauf schreiben soll. -
Ja, hatte ich ja auch schon geschrieben.
@thomas-braun
Der Kommentar von Meister Mopper am 24 Mar 2022, 17:29 fand ich interessant.
Aber so wie er geschrieben war konnte ich ihn nicht umsetzten und ich hatte Angst, dass wenn ich etwas falsch mache, ich das komplette System zerstöre.Ich kann mir folgendes vorstellen:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
2.) dass nach dem Neustart die Zugriffsrechte der Platte nicht richtig sind (diese muss ich nach dem Löschen und wieder herstellen manuell setzten) und deshalb influxDB den Fehler macht.Oder natürlich etwas anderes. Aber wie ich das rausfinden und beheben kann, weiß ich leider nicht.
Ich unterstütze gerne mit Logs und freue mich über alle Tipps. Danke
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
nofail,rw
Das sind zu wenig Optionen.
Ich würde da wenigstens 'defaults' noch setzen, besser noch den richtigen User, der drauf schreiben soll.@thomas-braun
Das hört sich nach meiner "Option 2" an. Kennst du dich da besser aus? Wie kann ich das Mouten "optimal" einstellen?- Also lange genug warten, dass infuxDB auf jeden Fall nach dem Mounten startet. Aber falls die Platte defekt ist, trotzdem nicht endlos hängen bleiben.
- InfluxDB oder besser alle Benutzer vollen schreibe und Lese Zugriffe haben
-
@thomas-braun
Der Kommentar von Meister Mopper am 24 Mar 2022, 17:29 fand ich interessant.
Aber so wie er geschrieben war konnte ich ihn nicht umsetzten und ich hatte Angst, dass wenn ich etwas falsch mache, ich das komplette System zerstöre.Ich kann mir folgendes vorstellen:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
2.) dass nach dem Neustart die Zugriffsrechte der Platte nicht richtig sind (diese muss ich nach dem Löschen und wieder herstellen manuell setzten) und deshalb influxDB den Fehler macht.Oder natürlich etwas anderes. Aber wie ich das rausfinden und beheben kann, weiß ich leider nicht.
Ich unterstütze gerne mit Logs und freue mich über alle Tipps. Danke
@mathias2803 sagte in Problems using influxDB on an external SSD:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
Die Reihenfolge wie Dienste gestartet werden kann man in systemd sehr genau definieren. Das mounten der Dateisysteme (per fstab) geschieht allerdings recht früh, das wird vermutlich nicht ursächlich sein.
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
Die Reihenfolge wie Dienste gestartet werden kann man in systemd sehr genau definieren. Das mounten der Dateisysteme (per fstab) geschieht allerdings recht früh, das wird vermutlich nicht ursächlich sein.
@thomas-braun
Und wie stelle ich die Zugriffsrechte richtig ein? -
@thomas-braun
Und wie stelle ich die Zugriffsrechte richtig ein?Schau in die man-page:
https://linux.die.net/man/8/mount
Da stehen alle Optionen für die einzelnen Dateisysteme drin.
-
Schau in die man-page:
https://linux.die.net/man/8/mount
Da stehen alle Optionen für die einzelnen Dateisysteme drin.
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw,users 0 2"
Oder wie stelle ich ein, dass jeder volle Zugriffsrechte auf die Platte hat?
-
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw,users 0 2"
Oder wie stelle ich ein, dass jeder volle Zugriffsrechte auf die Platte hat?
@mathias2803 sagte in Problems using influxDB on an external SSD:
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
Nein, lt. man page beschreibt das nur, dass jeder user das Dateisystem mounten darf.
Die Rechte ergeben sich aus den Rechten des mount-Punktes.Man kann nach dem mounten z. B. so in der Art die Rechte vergeben:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data -
@mathias2803 sagte in Problems using influxDB on an external SSD:
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
Nein, lt. man page beschreibt das nur, dass jeder user das Dateisystem mounten darf.
Die Rechte ergeben sich aus den Rechten des mount-Punktes.Man kann nach dem mounten z. B. so in der Art die Rechte vergeben:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data@thomas-braun said in Problems using influxDB on an external SSD:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data
Aber das kann ich dann nicht in "/etc/fstab" reinschreiben. Ich müsste es in einen Chronjob nach dem Start? Oder wie lege ich das fest? Ist das dann nicht wieder zu spät, also erst nachdem schon influxDB gestartet ist?
-
@thomas-braun said in Problems using influxDB on an external SSD:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data
Aber das kann ich dann nicht in "/etc/fstab" reinschreiben. Ich müsste es in einen Chronjob nach dem Start? Oder wie lege ich das fest? Ist das dann nicht wieder zu spät, also erst nachdem schon influxDB gestartet ist?
@mathias2803 sagte in Problems using influxDB on an external SSD:
/media/data
Wie sehen die Rechte an /media/data aus, wenn das Dateisystem nicht gemounted ist?
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
/media/data
Wie sehen die Rechte an /media/data aus, wenn das Dateisystem nicht gemounted ist?
@thomas-braun
Hast du mir nen Befehl, mit dem ich dir das rausfinden kann? Sorry. Bin nicht so fit mit Unix. -
@thomas-braun
Hast du mir nen Befehl, mit dem ich dir das rausfinden kann? Sorry. Bin nicht so fit mit Unix.ls -la /media/mySSD -
ls -la /media/mySSDpi@ioBroker:~ $ ls -la /mnt/mySSD insgesamt 628 drwxr-xr-x 5 root root 4096 Okt 1 2021 . drwxrwxrwx 3 root root 4096 Sep 23 2021 .. drwxrwxrwx 2 root root 614400 Apr 12 02:00 Influx-BackUp drwxrwxrwx 5 root root 4096 Okt 1 2021 InfluxDB drwx------ 2 root root 16384 Sep 28 2021 lost+found -
pi@ioBroker:~ $ ls -la /mnt/mySSD insgesamt 628 drwxr-xr-x 5 root root 4096 Okt 1 2021 . drwxrwxrwx 3 root root 4096 Sep 23 2021 .. drwxrwxrwx 2 root root 614400 Apr 12 02:00 Influx-BackUp drwxrwxrwx 5 root root 4096 Okt 1 2021 InfluxDB drwx------ 2 root root 16384 Sep 28 2021 lost+foundUnd das Dateisystem ist nicht gemounted?
Dann muss der Mountpunkt leer sein.
Support us
900
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge