UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Mathias2803]

@thomas-braun said in Problems using influxDB on an external SSD:

/dev/sda does not contain a filesystem or disklabel

Was kann da falsch sein? Ich kann normal darauf zugreifen und lesen und schreiben.

Ich habe auf einer Seite gelesen, dass es falsch eingebunden ist und man nur mit Root Rechten darauf zugreifen kann und es daran liegen soll.

pi@ioBroker:~ $ ls -l /media
insgesamt 32
lrwxrwxrwx 1 root root    4 Sep 28 15:54 usb -> usb0
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb0
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb1
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb2
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb3
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb4
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb5
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb6
drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb7

Wie kann ich das Problem beheben??

[Mathias2803]

@thomas-braun Kann ich noch etwas machen? Ich habe leider das Problem immer noch nicht gelöst.

[Thomas Braun]

@mathias2803

Keine Ahnung. Mir ist immer noch nicht klar, wie das Dateisystem gemounted wird. Per automount?

[crunchip]

@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

[Thomas Braun]

@crunchip

Ja, hatte ich ja auch schon geschrieben.

[Mathias2803]

@thomas-braun

Das mouten passiert durch "/etc/fstab" und dem Eintrag:

"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw 0 2"

[Mathias2803]

@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...

[Thomas Braun]

@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.

[Mathias2803]

@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]

@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]

@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]

@thomas-braun
Und wie stelle ich die Zugriffsrechte richtig ein?

[Thomas Braun]

@mathias2803

Schau in die man-page:

https://linux.die.net/man/8/mount

Da stehen alle Optionen für die einzelnen Dateisysteme drin.

[Mathias2803]

@thomas-braun

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?

[Thomas Braun]

@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]

@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]

@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]

@thomas-braun
Hast du mir nen Befehl, mit dem ich dir das rausfinden kann? Sorry. Bin nicht so fit mit Unix.

[Thomas Braun]

@mathias2803

ls -la /media/mySSD

[Mathias2803]

@thomas-braun

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+found