Ubuntu - USB-Sticks plötzlich schreibgeschützt

**Roscoe** · 12.10.2013 17:20

Seit kurzer Zeit kann ich von meinem Ubuntu-Laptop nichts mehr auf Sticks ziehen, jedes Mal bekomme ich die Meldung, der Stick sei schreibgeschützt.

Verändert wurde nichts, weder am Gerät (kein Schreibschutz-Umstecker!) noch am Laptop. Getestet mit mehreren USB-Sticks, gestern gingen zwei nicht, heute ist plötzlich auch der dritte schreibgeschützt.

Das macht das Arbeiten etwas schwierig, wie kann ich dieses willkürliche Rechteverändern verhindern?

**Lookbehind** · 12.10.2013 17:49

Ursachenforschung:
Stick an stecken => versuchen was drauf zu schreiben => Fehlermeldung bekommen und hier rein kopieren => Terminal öffnen => mount eingeben und das Ergebnis hier posten => ls -l /pfad/zum/stick eingeben und auch das Ergebnis hier posten.

**Roscoe** · 12.10.2013 18:49

Fehlermeldung:

Code:

Fehler beim Kopieren nach >>WINPROGRAMS<<.

Das Ziel ist schreibgeschützt.

mount-Befehl:

Code:

roscoe@ThinkPad-X130e:~$ mount
/dev/sda2 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /sys/firmware/efi/efivars type efivarfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
/dev/sda1 on /boot/efi type vfat (rw)
gvfsd-fuse on /run/user/roscoe/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=roscoe)
/dev/sdb1 on /media/roscoe/WINPROGRAMS type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)

Rest:

Code:

roscoe@ThinkPad-X130e:~$ ls -l /media/roscoe
insgesamt 16
drwx------ 9 roscoe roscoe 16384 Jan  1  1970 WINPROGRAMS

***foobar*** · 13.10.2013 01:48

Man kann natürlich auch immer mal ins Syslog gucken, da kann auch was stehen.

Ferner rate ich von »mount« zur Fehlerdiagnose ab, da das Ding nur die /etc/mtab ausgibt (also wie sein sollte). Den aktuellen Zustand des Kernel verrät einem statt dessen »cat /proc/mounts«. Da sieht man dann z.B. bei meinem Kubuntu, dass er die Option »errors=remount-ro« eigenmächtig ergänzt hat, was den Kernel veranlasst, bei Problemen (z.B. Wackelkontakt am USB-Verbinder, Probleme mit dem Bus etc.) das Medium schreibgeschützt neu einzubinden. Könnte eine Erklärung für das beobachtete Verhalten sein. Das müsste dann im Syslog stehen.

Ansonsten könnte man noch die Dateisysteme prüfen (vielleicht ist ja beim Aushängen was schief gelaufen und nun ist die FAT angeknackst). Und mit den mtools kann man die DOS-Attribute nochmal prüfen (obwohl der Kernel die eigentlich ignorieren sollte).

**Roscoe** · 13.10.2013 15:02

Ich verstehe ehrlich gesagt nicht viel von dem, was du mir mitteilen möchtest. ro steht vermutlich für read-only, was genau mounten ist, weiß ich leider nicht. Ich habe Sticks bisher immer einfach abgezogen, hat bisher noch nie Fehler verursacht. Könnte es daran liegen?
Andererseits, gestern hatte ich auf "Sicher entfernen" geklickt, selbes Problem.

cat /proc/mounts

Code:

roscoe@ThinkPad-X130e:~$ cat /proc/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=3873272k,nr_inodes=968318,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=776564k,mode=755 0 0
/dev/disk/by-uuid/1b06fc13-e319-4e74-bb5e-3abf7c9d03e4 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/cgroup tmpfs rw,relatime,size=4k,mode=755 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /sys/firmware/efi/efivars efivarfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0
/dev/sda1 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
gvfsd-fuse /run/user/roscoe/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
/dev/sdb1 /media/roscoe/WINPROGRAMS vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro 0 0

***foobar*** · 13.10.2013 16:31

Zitat von Roscoe

ro steht vermutlich für read-only

Jupp.

was genau mounten ist, weiß ich leider nicht

Eieiei. Wie erkläre ich das jetzt am besten?

Also, Grundlagen: Damit man Dateien auf einem Datenträger (Festplatte, USB-Stick, Diskette, SD-Karte, was auch immer) speichern kann, braucht der ein Dateisystem. Ein Dateisystem regelt, wie Dateien so auf dem Datenträger abgelegt werden, dass man sie später auch wieder findet. Kann man sich ein bisschen so vorstellen wie ein Ablagesystem im Aktenarchiv einer Firma oder Behörde. Wenn da jeder einfach seine Zettel auf den großen Haufen kippt, gerät nur alles durcheinander und man findet hinterher nix mehr wieder.

Also gibt es einen Archivar, der sich um alles kümmert. Der stellt da Regale auf. Jede Akte kommt feinsäuberlich in einen Ordner und der wird dann schön ordentlich ins Regal eingeräumt. Und dann gibt es noch einen zentralen Katalog, da schreibt der Archivar dann rein, wo genau er den Kram abgelegt hat. Wenn dann ein anderer die Akte sucht, muss der nicht das ganze Archiv von vorne bis hinten durchforsten, sondern er guckt im Katalog, wo der Ordner mit der Akte sein müsste und kann dann direkt zum richtigen Regal marschieren.

Nun gibt es auch nicht unbedingt das eine Ablagesystem, das alle verwenden, sondern verschiedene Systeme. Je nach Anforderungen und Archivgröße ist mal das eine besser und mal das andere. Auch kennt nicht jeder Archivar jedes Ablagesystem. Und so ist es auch mit den Dateisystemen. Da gibt es auch verschiedene von und je nach dem, was man braucht, wählt man dann das richtige aus. Das Dateisystem auf deinem USB-Stick ist FAT. Das ist alt (aus der DOS-Ära), damit kann praktisch jeder umgehen. Dafür kann es nicht viel und robust würde ich es auch unbedingt nicht nennen.

Mounten ist jetzt der Vorgang, wenn ein Dateisystem auf dem Datenträger ins Betriebsystem eingebunden wird. Da wird dann quasi der Katalog auf dem Datenträger einsortiert in den Gesamtkatalog des laufenden Systems. Der Archivar, der für alles zuständig ist, ist beim Computer natürlich keine Person, sondern das Betriebssystem. Das muss dann schauen, welches Dateisystem es ist und ob es damit umgehen kann (man kann Linux das Dateisystem raten lassen oder es auch beim Mounten vorgeben). Dann wird das Dateisystem in den großen Baum eingehängt. Unixe wie Linux haben ja keine Laufwerksbuchstaben, sondern nur eine Hierarchie und da kann man Dateisysteme reinhängen, wo man will (solange man die Rechte hat, versteht sich). Ubuntu hängt Wechselmedien immer unter /media ein.

Wenn der vorhandene Baum auf meinem Linux also in etwa so aussieht (gekürzte Darstellung):

Spoiler:

und das Dateisystem auf dem USB-Stick sieht so aus:

Spoiler:

Dann sieht das Ganze nach dem Einhängen unter /media/USBSTICK so aus:

Spoiler:

Die Mount-Option »errors=remount-ro« sagt nun folgendes: Wenn es zu einem Fehler kommt, dann soll das Medium bitte schreibgeschützt werden. Hintergrund ist, dass bei Fehlern (sei es durch defekte Verwaltungsinformationen oder auch Kabelprobleme oder ähnliches) jeder weitere Schreibzugriff alles nur noch schlimmer machen kann. Man kann sich nämlich dann nicht mehr darauf verlassen, dass die Daten wirklich da landen wo sie hin sollen. Es könnten andere, wichtige Daten verloren gehen. Also betreibt Linux hier automatische Schadensminderung: Schreibzugriffe gehen nicht mehr, dann kann dadurch auch nichts mehr kaputt gehen. Lesen geht aber noch, also kann man nun versuchen zu retten, was noch zu retten ist.

Ich habe Sticks bisher immer einfach abgezogen, hat bisher noch nie Fehler verursacht. Könnte es daran liegen?

Ja, das kann es! Das soll man nicht machen. Übrigens kann man sich damit auch unter Windows das Dateisystem kaputt machen, das ist kein spezielles Linux-Problem. Wechselmedien (sofern sie nicht wie DVDs sowieso keinen Schreibzugriff erlauben) muss man immer „sicher entfernen”.

Warum? Weil das Betriebsystem mit einem Zwischenspeicher arbeitet. Die meisten Wechselmedien sind nämlich langsam. Wenn man dann eine Datei auf das Medium kopiert, geht die erst mal in den schnellen Zwischenspeicher, dadurch ist der Kopiervorgang schnell erledigt und man kann schon mal weiter arbeiten. Im Hintergrund schreibt das OS dann die Datei nach und nach auf das Medium. So schnell bzw. langsam es eben geht und wie neben anderen Aufgaben auch gerade Zeit ist.

Wenn du jetzt den Stick einfach so abziehst, gibt es keine Garantie, dass das System den Zwischenspeicher bereits komplett geleert hat. Kann sein, es war noch gar nicht fertig mit Schreiben und dann kann alles mögliche passieren. Inkonsistenzen im Dateisystem (also fehlerhafte Verwaltungsinformationen) mit eingeschlossen.

Beim sicheren Entfernen schreibt das System den Zwischenspeicher leer und hängt das Dateisystem wieder aus, so dass danach auch keiner mehr mit noch einem Schreibversuch kommen kann (sonst hätte man ja wieder das selbe Problem).

Theoretisch gibt es noch eine andere Methode: Man kann den Datenträger synchron einbinden (das geht über die »sync« Option beim Mount-Befehl). Dann wird der Zwischenspeicher nicht benutzt und es wird immer alles direkt und sofort auf den Datenträger geschrieben. Dann sollte man eigentlich auch ohne Aushängen den Datenträger entfernen können. Allerdings dauern dann natürlich alle Zugriff ewig lange, weil ja nichts mehr gepuffert wird. Das ist der Modus, den DOS und Windows früher bei den alten Diskettenlaufwerken benutzt haben. Deshalb konnte man die da auch immer einfach so auswerfen. Bei USB-Sticks macht Windows es aber inzwischen auch nicht mehr – aus gutem Grunde.

Andererseits, gestern hatte ich auf "Sicher entfernen" geklickt, selbes Problem.

Wenn das Dateisystem schon kaputt ist, dann wird es natürlich nicht mehr dadurch geheilt, dass man in Zukunft alles richtig macht. Dann muss man das von Hand reparieren.

Wenn der USB-Stick bzw. seine einzige Partition also unter /dev/sdb1 zu finden ist, lautet der Befehl zum Prüfen des Dateisystems:

Code:

# fsck /dev/sdb1

Eingebunden darf der Stick übrigens zu diesem Zeitpunkt nicht sein und man braucht root-Rechte. fsck wird dann bei Fehlern fragen, was es machen soll. Mit der Option »-a« versucht es eine automatische Reparatur ohne Rückfragen, aber dann verliert man halt Einflussmöglichkeiten.

Allerdings repariert das nur das Dateisystem (also die Verwaltungsinformationen). Nutzdaten können trotzdem hinüber sein! Das muss man selber prüfen (das Betriebssystem weiß ja nicht, was da eigentlich stehen sollte).

Alternativ kann man mit:

Code:

# mkfs.msdos -n LABEL /dev/sdb1

ein neues, leeres und sauberes Dateisystem anlegen (alte Daten gehen dabei natürlich verloren). Das Wort »LABEL« kann man frei wählen (max. 11 Zeichen) und wird zur späteren Datenträgerbezeichnung.

Das wäre dann auch meine konkrete Empfehlung: Wenn nichts wichtiges auf dem Stick drauf ist, erstelle ein neues Dateisystem (das nennt man auch „Formatieren”, vielleicht schon mal gehört den Begriff) und gucke, ob das Problem dann wieder auftritt. Und in Zukunft immer brav „sicher entfernen”!

**Roscoe** · 15.10.2013 17:14

Danke für die umfassende und anschauliche Erklärung.

Beim Ausführen fangen die Probleme dann allerdings wieder an:

Zitat von foobar

Wenn das Dateisystem schon kaputt ist, dann wird es natürlich nicht mehr dadurch geheilt, dass man in Zukunft alles richtig macht. Dann muss man das von Hand reparieren.

Wenn der USB-Stick bzw. seine einzige Partition also unter /dev/sdb1 zu finden ist, lautet der Befehl zum Prüfen des Dateisystems:

Code:

# fsck /dev/sdb1

Eingebunden darf der Stick übrigens zu diesem Zeitpunkt nicht sein und man braucht root-Rechte. fsck wird dann bei Fehlern fragen, was es machen soll. Mit der Option »-a« versucht es eine automatische Reparatur ohne Rückfragen, aber dann verliert man halt Einflussmöglichkeiten.

Stick darf nicht angeschlossen sein, root-Rechte (hab ich die als Benutzer automatisch oder muss ich mir die per "sudo" besorgen - oder verwechsel ich das gerade mit Adminrechten - bitte eine Schritt für Schritt-Anleitung für Anfänger) muss ich haben; was ich mit dem -a soll, versteh ich nicht.

Plattmachen möchte ich ihn nicht unbedingt, nur im Notfall. Es scheinen ja auch mehrere betroffen zu sein.

Wenn ich den Befehl so ins Terminal tippe, erhalte ich folgende Meldung:

Code:

roscoe@ThinkPad-X130e:~$ fsck /dev/sdb1
fsck von util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext2: Datei oder Verzeichnis nicht gefunden beim Versuch, /dev/sdb1 zu öffnen
Ist das Gerät möglicherweise nicht vorhanden?

***foobar*** · 15.10.2013 19:25

Naja, ich will’s mal versuchen mit einer Anleitung. Generell würde ich aber empfehlen, dass du dich mit den entsprechenden Grundlagen vertraut machst. Dann kannst dir nämlich i.d.R. selber erschließen, was zu tun ist.

Also, zuerst Terminal aufmachen.
Dort eingeben: »sudo -i«, Enter drücken und Passwort eingeben. Jetzt biste (in diesem Terminal!) root und musst nicht immer sudo davor wurschteln.
Den Stick anpröppeln.
Kurz warten, dann »dmesg« eingeben. Dann siehst du, welche Gerätebezeichnung der Stick hat. Bei mir sieht das z.B. so aus:

Spoiler:(zum lesen bitte Text markieren)

(Dinge, die dich nix angehen, habe ich verpixelt, also nicht wundern! )
[Bild: dmesg1.png]

Interessant ist jetzt die zweitletzte Zeile mit der rosa Markierung. Da sieht man zwei Dinge: Der Stick selbst ist als /dev/sdj registriert worden. Und die einzige Datenpartition darauf hat dann die Nummer 1 gekriegt, mithin ist die Partition also als Gerät /dev/sdj1 zu finden. Das ist das, was wir gleich brauchen werden.
Dann also fsck mit dem Gerätenamen aufrufen. Bei mir wäre es demnach »fsck /dev/sdj1«.
Was dann kommt, hängt davon ab, was er findet, da musst du selber gucken.

**Roscoe** · 16.10.2013 17:00

Okay, hab alles befolgt und bei der Frage eine 1 eingetippt, mit Enter bestätigt, änder aber leider nichts.

Code:

root@ThinkPad-X130e:~# fsck /dev/sdb1
fsck von util-linux 2.20.1
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving file system unchanged.
/dev/sdb1: 10254 files, 411382/488304 clusters

***foobar*** · 16.10.2013 17:07

Als root mit »tail -n0 -f /var/log/syslog« das Syslog beobachten, dann den Stick einstecken, einbinden und versuchen, was drauf zu schreiben. Alles was dann ins Fenster geschrieben wird, hier posten.

**Roscoe** · 16.10.2013 19:01

Hat erstmal ewig gedauert, bis die ersten zwei Zeilen da standen.

Schreiben hat übrigens geklappt.

Code:

root@ThinkPad-X130e:~# tail -n0 -f /var/log/syslog
Oct 16 19:17:01 ThinkPad-X130e CRON[19669]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 16 19:18:19 ThinkPad-X130e wpa_supplicant[1285]: eth1: WPA: Group rekeying completed with 00:23:08:89:f7:9f [GTK=TKIP]
Oct 16 19:57:50 ThinkPad-X130e kernel: [ 7494.628013] usb 1-3: new high-speed USB device number 5 using ehci-pci
Oct 16 19:57:50 ThinkPad-X130e kernel: [ 7494.761230] usb 1-3: New USB device found, idVendor=0781, idProduct=5567
Oct 16 19:57:50 ThinkPad-X130e kernel: [ 7494.761247] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 16 19:57:50 ThinkPad-X130e kernel: [ 7494.761255] usb 1-3: Product: Cruzer Blade
Oct 16 19:57:50 ThinkPad-X130e kernel: [ 7494.761263] usb 1-3: Manufacturer: SanDisk
Oct 16 19:57:50 ThinkPad-X130e kernel: [ 7494.761271] usb 1-3: SerialNumber: 20051738820578B120C1
Oct 16 19:57:50 ThinkPad-X130e kernel: [ 7494.763307] scsi3 : usb-storage 1-3:1.0
Oct 16 19:57:50 ThinkPad-X130e mtp-probe: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3"
Oct 16 19:57:50 ThinkPad-X130e mtp-probe: bus: 1, device: 5 was not an MTP device
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.763287] scsi 3:0:0:0: Direct-Access     SanDisk  Cruzer Blade     1.03 PQ: 0 ANSI: 2
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.768162] sd 3:0:0:0: Attached scsi generic sg1 type 0
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.772995] sd 3:0:0:0: [sdb] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.774718] sd 3:0:0:0: [sdb] Write Protect is off
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.774728] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.777784] sd 3:0:0:0: [sdb] No Caching mode page present
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.777796] sd 3:0:0:0: [sdb] Assuming drive cache: write through
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.787597] sd 3:0:0:0: [sdb] No Caching mode page present
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.787609] sd 3:0:0:0: [sdb] Assuming drive cache: write through
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.794096]  sdb: sdb1
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.799432] sd 3:0:0:0: [sdb] No Caching mode page present
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.799446] sd 3:0:0:0: [sdb] Assuming drive cache: write through
Oct 16 19:57:51 ThinkPad-X130e kernel: [ 7495.799454] sd 3:0:0:0: [sdb] Attached SCSI removable disk
Oct 16 19:57:51 ThinkPad-X130e udisksd[3002]: Mounted /dev/sdb1 at /media/roscoe/WINPROGRAMS on behalf of uid 1000
Oct 16 19:58:08 ThinkPad-X130e dbus[914]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper)
Oct 16 19:58:08 ThinkPad-X130e dbus[914]: [system] Successfully activated service 'org.freedesktop.hostname1'

**Lookbehind** · 16.10.2013 19:09

Zitat von Roscoe

Okay, hab alles befolgt und bei der Frage eine 1 eingetippt, mit Enter bestätigt, änder aber leider nichts.

Code:

root@ThinkPad-X130e:~# fsck /dev/sdb1
fsck von util-linux 2.20.1
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving file system unchanged.
/dev/sdb1: 10254 files, 411382/488304 clusters

Was du hier erlebt hast ist folgendes: Du hast den Stick irgendwann mal abgezogen, ohne dass er vorher vernünftig ausgehängt wurde. Das wurde auf dem Dateisystem auch hinterlegt, Ubuntu hat das erkannt, ist aber davon ausgegangen, dass aus diesem Grund auch ein Fehler mit dem Dateisystem vorliegen muss und das Gerät aus Sicherheitsgründen nur Lesbar gemacht, um weiteren Schaden zu vermeiden.
In diesem Fall würde ich sagen: Glück gehabt! Aber in Zukunft vielleicht doch besser vorher den Stick vernünftig aushängen, bevor man ihn abzieht

***foobar*** · 16.10.2013 19:49

Hmm... ich sehe keine Problem in dem Log.

Was man noch versuchen kann:

Einbinden und Ausgabe von »ls -la /media/roscoe/WINPROGRAMS/« bzw. wie der jeweilige Pfad eben lautet posten (wir wissen zwar, welche Rechte der Mountpoint hat, aber wie es auf dem Stick selbst aussieht, ist bisher unklar).
Testweise von Hand mounten anstatt über Unity. Also anstecken, dann wie bereits erklärt die Geräte-ID herausfinden (ich verwende hier mal beispielhaft /dev/sdc1) und anschließend als root folgende Befehle ausführen und deren Ausgabe posten:
# mount /dev/sdc1 /mnt
# touch /mnt/test
# ls -la /mnt/test

**Lookbehind** · 16.10.2013 19:53

Zitat von foobar

Hmm... ich sehe keine Problem in dem Log.
...

*foobar auf Schulter tippt* Ähm...

Zitat von Roscoe

...
Schreiben hat übrigens geklappt.
...

***foobar*** · 16.10.2013 19:57

Zitat von Lookbehind

*foobar auf Schulter tippt* Ähm...

Ich wollte natürlich nur mal gucken, ob ihr auch alle aufpasst! [Bild: pfeif.gif]

**Roscoe** · 16.10.2013 20:14

Zitat von Lookbehind

Aber in Zukunft vielleicht doch besser vorher den Stick vernünftig aushängen, bevor man ihn abzieht

Hab's bisher immer für übertriebene Vorsicht gehalten und nie Probleme damit gehabt. Aber wie man mal wieder sieht, lernt man wohl nie aus.

Zitat von foobar

Hmm... ich sehe keine Problem in dem Log.

Was man noch versuchen kann:

Einbinden und Ausgabe von »ls -la /media/roscoe/WINPROGRAMS/« bzw. wie der jeweilige Pfad eben lautet posten (wir wissen zwar, welche Rechte der Mountpoint hat, aber wie es auf dem Stick selbst aussieht, ist bisher unklar).
Testweise von Hand mounten anstatt über Unity. Also anstecken, dann wie bereits erklärt die Geräte-ID herausfinden (ich verwende hier mal beispielhaft /dev/sdc1) und anschließend als root folgende Befehle ausführen und deren Ausgabe posten:
# mount /dev/sdc1 /mnt
# touch /mnt/test
# ls -la /mnt/test

Okay, also dann kann ich mir das anscheinend ersparen, wenn alles soweit klappt. Welche Schritte muss ich denn nun für die anderen Sticks wiederholen?

**Lookbehind** · 16.10.2013 20:24

Zitat von Roscoe

Hab's bisher immer für übertriebene Vorsicht gehalten und nie Probleme damit gehabt.
...

Tausend mal berührt
Tausend mal ist nix passiert
Tausend und eine Nacht ...
*sing*

Zitat von Roscoe

...
Welche Schritte muss ich denn nun für die anderen Sticks wiederholen?

Hoffentlich nur, was dich zu diesem Ergebnis geführt hat.

Zitat von Roscoe

Okay, hab alles befolgt und bei der Frage eine 1 eingetippt, mit Enter bestätigt, änder aber leider nichts.

Code:

root@ThinkPad-X130e:~# fsck /dev/sdb1
fsck von util-linux 2.20.1
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving file system unchanged.
/dev/sdb1: 10254 files, 411382/488304 clusters

Wobei, nur weil einer der Sticks die Abzupferei vergleichsweise schadfrei überlebt hat, heißt das nicht, dass das bei den anderen auch so ist

**Roscoe** · 19.10.2013 10:36

Leider hast du wohl recht, der nächste Stick macht deutlich mehr Probleme.

Auszug aus desmg:

Code:

[  604.463013] scsi 2:0:0:0: Direct-Access              Spaceloop 8GB    8.07 PQ: 0 ANSI: 2
[  604.465280] sd 2:0:0:0: Attached scsi generic sg1 type 0
[  604.468586] sd 2:0:0:0: [sdb] 16441344 512-byte logical blocks: (8.41 GB/7.83 GiB)
[  604.469446] sd 2:0:0:0: [sdb] Write Protect is off
[  604.469463] sd 2:0:0:0: [sdb] Mode Sense: 03 00 00 00
[  604.470150] sd 2:0:0:0: [sdb] No Caching mode page present
[  604.470161] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[  604.477643] sd 2:0:0:0: [sdb] No Caching mode page present
[  604.477663] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[  604.541255]  sdb: sdb1
[  604.544139] sd 2:0:0:0: [sdb] No Caching mode page present
[  604.544149] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[  604.544156] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[  605.392340] FAT-fs (sdb1): error, fat_get_cluster: invalid cluster chain (i_pos 0)
[  605.392356] FAT-fs (sdb1): Filesystem has been set read-only
[  605.426826] systemd-hostnamed[14197]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
[  966.083096] sdb: detected capacity change from 8417968128 to 0
[  968.082367] usb 1-1: USB disconnect, device number 4
[  994.009601] usb 1-3: new high-speed USB device number 5 using ehci-pci
[  994.229233] usb 1-3: New USB device found, idVendor=058f, idProduct=6387
[  994.229249] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  994.229257] usb 1-3: Product: Spaceloop 8GB
[  994.229265] usb 1-3: SerialNumber: 79C95B7D
[  994.231444] scsi3 : usb-storage 1-3:1.0
[  995.230739] scsi 3:0:0:0: Direct-Access              Spaceloop 8GB    8.07 PQ: 0 ANSI: 2
[  995.233002] sd 3:0:0:0: Attached scsi generic sg1 type 0
[  995.234633] sd 3:0:0:0: [sdb] 16441344 512-byte logical blocks: (8.41 GB/7.83 GiB)
[  995.235662] sd 3:0:0:0: [sdb] Write Protect is off
[  995.235678] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00
[  995.237421] sd 3:0:0:0: [sdb] No Caching mode page present
[  995.237440] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[  995.242904] sd 3:0:0:0: [sdb] No Caching mode page present
[  995.242923] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[  995.301248]  sdb: sdb1
[  995.304364] sd 3:0:0:0: [sdb] No Caching mode page present
[  995.304382] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[  995.304394] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[  996.274546] FAT-fs (sdb1): error, fat_get_cluster: invalid cluster chain (i_pos 0)
[  996.274557] FAT-fs (sdb1): Filesystem has been set read-only
[  996.351977] systemd-hostnamed[20147]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!

fsck:

Code:

root@ThinkPad-X130e:~# fsck /dev/sdb1
fsck von util-linux 2.20.1
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
Seek to 8417967616:Invalid argument

***foobar*** · 19.10.2013 10:38

Tja, am einfachsten lässt sich das wohl per Formatierung lösen...

Da siehst du übrigens auch im Log (zweitletzte Zeile), dass er aufgrund des Fehlers in den Read-Only-Modus schaltet.

**Roscoe** · 19.10.2013 10:57

Zitat von foobar

Tja, am einfachsten lässt sich das wohl per Formatierung lösen...

Hab ich mir auch gedacht, den Stick weitesgehend geräumt (eine unwichtige Datei lässt sich nicht mehr öffnen oder entfernen) und versucht, ihn plattzumachen:

Code:

root@ThinkPad-X130e:~# mkfs.msdos -n SPACELOOP /dev/sdb1
mkfs.msdos 3.0.14 (23 Jan 2023)
mkfs.msdos: /dev/sdb1 contains a mounted file system.

Zitat von foobar

Da siehst du übrigens auch im Log (zweitletzte Zeile), dass er aufgrund des Fehlers in den Read-Only-Modus schaltet.

Ist mir aufgefallen. Find's gut, dass das Terminal so verständlich aufgebaut ist.

Ubuntu - USB-Sticks plötzlich schreibgeschützt

Themen-Optionen

Ubuntu - USB-Sticks plötzlich schreibgeschützt

Berechtigungen