ext3-Platte ist auf einmal nur noch read-only

[ka0t]

Ich wollte eben auf eine Platte ein paar Daten schieben und bekam die Meldung ich hätte keine Berechtigungen. Da ich an der fstab nichts geändert habe und vor ein paar Tagen auf der Platte gelöscht und kopiert habe muss es eigentlich funktionieren.
ls- al attestiert mir auch die Besitzrechte. Als ich nur einfach mal chown -R laufen ließ hagelte es Meldungen, das Dateisystem sei nur lesbar

chmod: Beim Setzen der Zugriffsrechte
Das Dateisystem ist nur lesbar

In der fstab ist alles wie gehabt

/dev/sdc1 /home/shares/Samsung ext3 defaults 0 1

Wo kann das Problem noch her sein ?

 

[Freggl]

Umount die Platte mal und mounte die nochmal von Hand:
mount -t ext3 -o rw /dev/sdbla /ordner/bla

 

[ka0t]

Mir ist die eine Platte anscheinend am abkratzen- beim Neustart hat fsck mit Statuscode 4 abgebrochen.
Kann ich es irgendwie verhindern, dass der server in einem solchen Fall nicht hochbootet und dann erst durch strg+d direkt über die Tastatur hochgelasen werden muss ?
Ich muss bisher jedes mal nen Monitor und eine Tastatur anschließen, wenn es zu einem Problem gekommen ist und er nicht bis zum Start des SSH-Dienstes kommt.

Im Log sind ein paar defekte Cluster/Lesefehler vermerkt. Vor einer Weile ist das sata-Kabel mal verrutscht und diese Platte dadurch unmountbar geworden.
Smartmontools hat keine kritischen Vermerke, jedoch ist eine ATA Bus-Error oft aufgeführt

Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4: SError: { HostInt Handshk }
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: cmd 61/f8:18:d7:cf:ae/03:00:0d:00:00/40 tag 3 ncq 520192 out
Sep  7 18:23:13 debianserver kernel: [123533.166294]          res 40/00:0c:d7:df:ae/00:00:0d:00:00/40 Emask 0x50 (ATA bus error)
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: status: { DRDY }
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: cmd 61/00:28:cf:d3:ae/04:00:0d:00:00/40 tag 5 ncq 524288 out
Sep  7 18:23:13 debianserver kernel: [123533.166294]          res 40/00:0c:d7:df:ae/00:00:0d:00:00/40 Emask 0x50 (ATA bus error)
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: status: { DRDY }
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: cmd 61/00:30:cf:d7:ae/04:00:0d:00:00/40 tag 6 ncq 524288 out
Sep  7 18:23:13 debianserver kernel: [123533.166294]          res 40/00:0c:d7:df:ae/00:00:0d:00:00/40 Emask 0x50 (ATA bus error)
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: status: { DRDY }
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: cmd 61/00:38:cf:db:ae/04:00:0d:00:00/40 tag 7 ncq 524288 out
Sep  7 18:23:13 debianserver kernel: [123533.166294]          res 40/00:0c:d7:df:ae/00:00:0d:00:00/40 Emask 0x50 (ATA bus error)
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4.00: status: { DRDY }
Sep  7 18:23:13 debianserver kernel: [123533.166294] ata4: hard resetting link

Die billige Spinpoint von der dieser Fehler herkommt kann meinetwegen draufgehen- es sind eh keine wichtigen Daten drauf.
Das komische ist nur das ich stellenweise auch auf der anderen Festplatte auch keine Schreibrechte mehr hatte.

 

[josen]

Hallo,

versuch doch erstmal dein Gehäuse, Kabel und Anschlüsse ordentlich zu reinigen und wenn das nicht hilft, deine Festplatte ohne DMA in einem PIO-Modus (lässt sich meist im BIOS einstellen) zu starten. Für mich klingt das nach Staub im Gehäuse.

In meinem Servergehäuse war ein fehlender Luftfilter vorm einsaugenden Lüfter für das selbe Problem verantwortlich. Ich suche noch heute nach bedruckbaren Foto-Dartscheiben ;-)

Grüße

 

[ka0t]

Das sind alles Sata- Platten. Das eine SAta noch im Pio läuft kann ich mir kaum vorstellen - zumal das Board soo alt auch nicht ist.
Ich werde vorsorglich die Kabel tauschen- zumindest das eine werde ich gegen eins mit Einrasthaken tauschen.
Ein Teil der zweiten Platte war noch temporät nicht beschreibbar (ein paar Subdirecotrys) - das hat sich dann von selbst aufgelöst 0.o

 

[Seratio]

Lies im Zweifel einfach die SMART Daten aus. Die lügen so gut wie nie. Und bei solchen Fehlern, sollte selbst SMART was mitbekommen haben.

 

[ka0t]

Im syslog bei cron.hourly ist smartmontools nichts am grossartig bemängeln. Nur der Wert Hardware ECC recovered wird als jeweils um den Wert 1 sinkend angegeben. Bei kritischen Meldungen müsste mich Smartmontools ja anschreien, dafür habe ich es schliesslich installiert. Das seltsame war ja das der Zugriff weiterhin schmerzfrei war nur eben dieses eine Recht nicht oder nur für Teile der Platten gesetzt war.

 

[[g]nex]

was sagt ein smartctl -d ata -a /dev/sdX

 

[ka0t]

Der Befehl meldete mir zurück:

SMART Error Log Version: 1
No Errors Logged

Irgendwas mit illegal Block stand beim booten (wieder nur durch strg d möglich) da.


EDITH: Die Platte gibt ein regelmässiges vibrieren, was zu einem summen und knarzen, das auf-und abschwellt wird, von sich...
Das hat sie vor einer Ewigkeit ab und an mal gemacht und mich damit fast in den Wahnsinn getrieben -_-
Hammertime ! :-D

Seltsam ist imo dennoch das der Lesezugriff stets einwandfrei war aber beide Platten dann als nur lesbar gemounted wurden und diese Attribute in Subdirectories noch unabänderbar weiter bestanden.

 

[ka0t]

Wie kann ich den fsck für diese Platte ausstellen ?
Es ist doch eigentlich schon doof, dass der server wegen der einen defekten Platte SSH nicht läd. Würde mein Server irgendwo beim Kunden stehen, müsste ich ihn mir alles vorlesen lassen. Kann man das auch irgendwie umstellen wie es beim Bios möglich ist "halt on no errors except ..."

 

[-->Andy<--]

  tune2fs -c 0 -i 0 /dev/sdXY

und in der fstab die letzte Zahl auf 0 stellen

 

[Seratio]

Da sollte sich was mit tune2fs machen lasen.

tune2fs -c 0 -i 0 </dev/partition>

MfG
Alex

---------- Beitrag hinzugefügt um 13:03 ---------- Vorheriger Beitrag war um 13:03 ----------

gnarf... da war wer schneller :P

 

[ka0t]

Danke
Die samsung schnurrt und knarzt rythmisch dem Tod entgegen