Weihnachtsangebot 2025! 🎄

[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

[Thomas Braun]

@mathias2803

Und das Dateisystem ist nicht gemounted?
Dann muss der Mountpunkt leer sein.

[Mathias2803]

@thomas-braun
Wie meinst du, dass das Dateisystem nicht gemountet ist??
An was siehst du das?

[Homoran]

@mathias2803 sagte in Problems using influxDB on an external SSD:

An was siehst du das?

eben nicht, das war Bedingung:

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

Wie sehen die Rechte an /media/data aus, wenn das Dateisystem nicht gemounted ist?

deswegen die Nachfrage

[Mathias2803]

@homoran

Das Verzeichnis media/data gibt es gar nicht. Woher kommt das und warum?

pi@ioBroker:~ $ sudo ls -la /media/data
ls: Zugriff auf '/media/data' nicht möglich: Datei oder Verzeichnis nicht gefunden

[Mathias2803]

@homoran

In der influxdb.conf taucht auch keine "media/data" auf sondern nur folgende Einstellungen:

[meta]
  dir = "/mnt/mySSD/InfluxDB/meta"
[data]
  dir = "/mnt/mySSD/InfluxDB/data"
  wal-dir = "/mnt/mySSD/InfluxDB/wal"
  series-id-set-cache-size = 100
[http]
  enabled = true
  bind-address = ":8086"
  auth-enabled = false
  log-enabled = true
  write-tracing = false
  pprof-enabled = false
  https-enabled = false
  https-certificate = "/etc/ssl/influxdb.pem"

Alles andere sind nur Kommentare.