Kodi Mag seine Laufwerke nicht mehr Mounten

ok, man darf wohl vorher nicht mit SMB auf die Platte zugreifen, sonst unmountet er sie nicht

nach booten

LibreELEC:~ # umount /dev/sdb1
LibreELEC:~ # e2fsck -f /dev/sdb1
e2fsck 1.46.6 (1-Feb-2023)
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
SamsungSSD: 50272/7331840 files (0.8% non-contiguous), 16985211/29304575 blocks
LibreELEC:~ #

also gibt es einen Fehler mit "0.8 %" ? Sehe ich das richtig?

Also wird es nix mit NTFS zu tun haben. NTFS kann von LE bloss nicht repariert werden. Das scheiternde umount wird wohl beim Runterfahren dafür sorgen, dass das Dateisystem kaputt geht.

Wenn ich nach einer SMB Übertragung alles Dateifenster am PC schließe, nimmt er irgendwann den Befehl "umount /dev/sdb1" an. Kann mal LE nicht dazu zwingen solange in einer Schleife zu bleiben bis der Befehl erfolgreich war? bzw. kann er nicht selbstständig offene SMB Processe abschießen?

Zitat von ChristianundCo

also gibt es einen Fehler mit "0.8 %" ? Sehe ich das richtig?

Nein, da ist kein Fehler zu sehen. 0,8% ist der "Fragmentierungs-Grad" der Dateien (wie auch immer genau definiert). Dass halt mal ne große Datei auf der Platte nicht alle Bytes genau hintereinander abgespeichert hat, sondern in (wenigen) Blöcken mit was anderem dazwischen. Das ist während normalen Betriebs mit Schreib und Lösch-Aktionen nicht zu verhindern und nicht schlimm. Ich sag mal (nicht nur) bei SSD sowieso am besten ignorieren, insbesondere wenn der Wert niedrig ist.

OK, aber ich bleibe bei der starken Vermutung, dass ein SMB Zugriff das Unmounten verhindert und daher Dateisystem (auch andere als NTFS) kaputtgehen.

Normalerweise sollten beim Runterfahren eines Linux ja auch Dateisysteme sicher ungemounted werden, weil ja die zugehoerigen Prozesse gekillt werden. Allerdings hat dieses Prinzip in meiner schon etwas vernebelten Erinnerung eigentlich noch nie so richtig geklappt wenn so ein Dateisystem ueber ein im Kern befindliches Netzwerkfilesystem exportiert ist. weil dann halt kein Prozess wie smbd alleine dafuer verantwortlich ist, das das Dateisystem sicher ungemounted werden kann, sondern eben auch das andere netzwerkdateisystem im Kernel. Was zumindestens frueher nicht wirklich gekillt werden konnte.

Frueher hat man solche Probleme immer nur mit NFS gehabt, aber wenn jetzt halt SMB auch im Kern laeuft, dann halt auch bei SMB. Evtl. hat da debian/LE noch nicht alle brutalen tricks eingebaut die es gibt, aber ich hab mir das schon seit Ewigkeiten nicht mehr angeschaut *sigh*.

Wie schon gesagt, die generell beste Loesung um zu verhindern das beim nicht perfekten Herunterfahren so ein NTFS fielssystem kaputtgeht (und dann an Windows repariert werden muss) ist halt das read-only zu mounten. Da musst DU aber im LE zimindestens wohl ein config-file editieren/erstellen oder so. Und dann halt, wenn Du was uebers netz draufkopieren willst das Dateisystem per ssh erstmal wieder read/write mounten und nach der Kopieraktion wieder auf read-only.

Kannst natuerlich auch versuchen smb per ssh manuell zu starten/stoppen und umount usw machen.

Aber das ist halt alles Moppelkotze.

Wie haeufig wurde hier im thread empohlen, einfach ext4 zu verwenden ?

Solange ich nicht 100%-g weiß, dass das Problem mit Ext4 behoben wäre, steige ich nicht um. Ich betreibe noch Ursachenforschung

Was ist denn das Problem was Du geloest kriegen willst ?

a) Das Du die Platte zu einem Windows rechner schleppen musst um das Filesystem repariert zu kriegen ?

b) Das das Filesystem repariert werden muss ?

c) <insert your favorite problem>

Wer sagt mir, dass Ext4 mit meiner jetzigen Konfig nicht auch kaputt geht?

Ich glaube mal, die Chance das das nach einem shutdown ohne unmount in einem inkonsistenten zustand ist ist halt niedriger als bei einem neuen NTFS im Kernel. Beim Runterfahren wird ja vom Kernel auch ein sync gemacht, das funktioniert bei ext4 eigentlich ganz gut. Wer weiss, wie das beim kernel NTFS ist, das ist ja ganz neu. Ansonsten wird das ext4 halt auch automatisch beim booten repariert, wenns halt mal doch nicht geklappt hat. Und das geht eigentlich immer auch aus dem journal, also schnell.

Aka: bei ext4 mache ich mir keine sorgen das ich da mit unsauberem runterfahren was kaputt mache was nicht automatisch repariert werden kann. ausser irgendwie bei microSD Karten im RPI, aber das ist irgendwas ganz merkwuerdiges.

Aber klar, das ist kein guter finales Ergebnis und ich wuerde das auch nicht bei Platten/Daten machen, die nicht einfach bloss Kopien auf einem HTPC sind. Aber primaer daten liegen halt bei mir nie auf einem HTPC sondern auf einem Server.

OK, ich habe jetzt mal alles platt gemacht und LE 11.01 vom Stick aus ganz neu installiert (mit Vollformatierung der internen SSD Platte). Die externen USB Platten habe ich noch nicht angesteckt.

Und dann habe ich mal ne "sleep 12" Zeile in die shutdown.sh geschrieben. Damit ich die letzten Zeilen lesen kann nach dem Runterfahren.

Und es erscheint nach wie vor: "failed unmounting storage.mount"

Das ist schonmal doof

Also hat er Probleme die interne Ext... SSD unzumounten

War das mit vorher per SMB auf die Platte zugreifen oder selbst wenn Du gebootest hast, dann gar nicht auf die Platte via SMB zugegriffen hast, und dann runtergefahren hast ?

vielleicht sollten wir uns auf terminologie einigen:

"kaputtgehen" so wie @DaVu es benutzt heisst, das das Filesystem nicht durch einen filesystem-check in ordnung gebracht werden kann. Also Datenverlust. Das ist eigentlich bei allen aktuellen Datensystem nicht moeglich, weil die alle Vorkehrungen dagegen haben. Journaling, Logging oder andere. NTFS macht z.b. auch journaling.

btrfs z.b. hat Logging anstelle von Journaling. Und sollte deswegen beim schreiben sogar schneller sein. Allerdings war meine Erfahrung vor mehreren Jahren leider eher das das Filesystem bei ploetzlichem Stromverlust doch komplett kaputt war.

Geht also imho auch darum, deine eine implementierung bullet-proof ist. Und das ist ext halt viel mehr als btrfs und insbesondere ntfs3 (also die neue kernel level linux implementierung in LE11).

Aber noch viel vordergruendiger gehts halt darum, das linux gar kein komplette "reparatur" tool (fsck) mitbringt.

Ansonsten ist es eigentlich immer gut, wenn man beim booten den bootlog sieht.

Wenn man dort sieht "restoring journal". Dann ist alles ok. Dann hat man halt bloss das voellig unterstuetzte feature "strom weg ohne unmount" genutzt.

Sobald der fsck mal mehr machen muss sollte man sich fragen, warum es dazu kam.

So zumindestens bei ext4.

Zitat von te36

War das mit vorher per SMB auf die Platte zugreifen oder selbst wenn Du gebootest hast, dann gar nicht auf die Platte via SMB zugegriffen hast, und dann runtergefahren hast ?

Das kommt scheinbar immer. Egal was ich mache. (Seit LE 11.01)

mus man mal in der cli rumspielen. evtl. reichen ein paar zusaetzliche befehle oder so um das zu fixen. smbd sauber beenden oder so.

Habe mal den ganzen SMB-Dienst und SSH-Dienst ausgeschaltet und das Netzwerkkabel gezogen. Gebootet und gleich wieder runtergefahren. Die Meldung "failed unmounting...." bleibt

Entfern mal die beiden folgenden Zeilen aus dem LE Script

# Just to annoy ChristianundCo

echo "failed unmounting...."

Jaja, sorry, im Moment gerade nur Galgenhumor.

Aber eigentlich gutes Zeichen. Entfernt schon mal eine Komplexitaet aus dem Problem.

Komme im Moment leider nicht dazu das mir selbst bei LE anzuschauen. Hoffentlich ein wenig spaeter.

Ich habe jetzt Version LE 10.04 installiert. Und da habe ich folgendes fotografiert.

Wenn ich bei 10.04 aber den SMB-Dienst deaktiviere, kommt diese Meldung nicht mehr.

Und jetzt das selbe mit 11.01

Da macht es keinen Unterschied ob ich SMB an oder aus habe. Die Fehlermeldung kommt da immer, ohne dass irgend ein Addon installiert ist oder irgendein Dienst.

Hehe, hoert sich ja fast so an, als ob Du das aussitzen kannst. Loesung wird von alleine mit Update kommen

Wenns schneller gehen sollte, dann am besten den Fehler direkt beim LE Forum melden, ausser @DaVu will/kann da direkt was machen. Aber selbst wenn wir hier das noch genauer eingrenzen und einen fix finden: Einbauen muss den ja eh jemand von der LE Seite.