Debian 9 - USB-Stick wird nur im Lesemodus gestartet

[leere8sam]

Hallo zusammen,
ich bin ein Debian-Neuling und komme zur Zeit mit dem Problem nicht weiter, dass ich von meinem Debian-Notebook nur im lesenden Modus auf meinen USB-Stick zugreifen kann. Interessanterẃeise kann ich den USB-Stick unter Win10 und LEAP einwandfrei im "Schreib-Lese-Modus" aktivieren und manchmal habe ich auch für kurze Zeit schreibenden Zugriff auf den Stick auf meinem Debian-Notebook, aber das hält nicht lange an. Angefangen haben die Probleme damit, dass der Stick unter Win10 automatisch "repariert" wurde.
Zu diesem Thema habe ich einen Thread unter
https://forums.opensuse.org/showthread. ... leme/page3
erstellt, da das Thema aber Debian betrifft, halte ich es für zweckmäßig, den Thread hier weiterzuführen.
Aktuelle Ausgaben:

Code: Alles auswählen

marcel@dellnotebook:~$ lsblk -f
NAME                        FSTYPE      LABEL     UUID                                   MOUNTPOINT
sda                                                                                      
├─sda1                      ext2                  da4b7838-7b91-4554-ae68-985dbd3d644b   /boot
├─sda2                                                                                   
└─sda5                      LVM2_member           kBGmOG-HC2A-4mic-SybG-PfYm-l2VO-FMS8PG 
  ├─dellnotebook--vg-root   ext4                  62985f4b-9f95-4b72-b0a2-713f74bf8ea1   /
  ├─dellnotebook--vg-swap_1 swap                  fad70c50-5bd2-484a-bf80-c704afc4b2d0   [SWAP]
  └─dellnotebook--vg-home   ext4                  e8819139-7e4f-4ee1-bfcf-12d9deb49f09   /home
sdb                         vfat        Transcend 11EA-2C2A                              /media/marcel/Transcend
sr0                                                                                      
marcel@dellnotebook:~$ 

Code: Alles auswählen

marcel@dellnotebook:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1959856k,nr_inodes=489964,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=394344k,mode=755)
/dev/mapper/dellnotebook--vg-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=562)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
/dev/sda1 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl)
/dev/mapper/dellnotebook--vg-home on /home type ext4 (rw,relatime,data=ordered)
tmpfs on /run/user/117 type tmpfs (rw,nosuid,nodev,relatime,size=394340k,mode=700,uid=117,gid=123)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=394340k,mode=700,uid=1000,gid=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdb on /media/marcel/Transcend type vfat (ro,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=394340k,mode=700)
marcel@dellnotebook:~$

Mein USB-"Transcend"-Stick ist jeweils als "sdb" aufgeführt.
Bitte lasst es mich wissen, wie wir hier weiter kommen können.
Danke und Grüße!

[DeletedUserReAsG]

Bitte lasst es mich wissen, wie wir hier weiter kommen können.

Ein Blick in die Ausgabe von dmesg während des Einsteckens sollte Hinweise auf die Ursache liefern. Häufigste Ursache bei vfat: nicht sauber ausgehängte (i.e. einfach abgezogene) Sticks.

[leere8sam]

Danke!

Code: Alles auswählen

root@dellnotebook:/home/marcel# dmesg
[    0.000000] Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11)
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.0-9-amd64 root=/dev/mapper/dellnotebook--vg-root ro quiet
 ....
 2292.272566] TCP: enp10s0: Driver has suspect GRO implementation, TCP performance may be compromised.
[ 2910.162391] usb 2-1.3: new high-speed USB device number 4 using ehci-pci
[ 2910.272087] usb 2-1.3: New USB device found, idVendor=8564, idProduct=1000
[ 2910.272096] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2910.272102] usb 2-1.3: Product: Mass Storage Device
[ 2910.272107] usb 2-1.3: Manufacturer: JetFlash
[ 2910.272112] usb 2-1.3: SerialNumber: 2655370810
[ 2910.361802] usb-storage 2-1.3:1.0: USB Mass Storage device detected
[ 2910.362000] scsi host6: usb-storage 2-1.3:1.0
[ 2910.362146] usbcore: registered new interface driver usb-storage
[ 2910.375940] usbcore: registered new interface driver uas
[ 2911.379895] scsi 6:0:0:0: Direct-Access     JetFlash Transcend 64GB   1.00 PQ: 0 ANSI: 6
[ 2911.381107] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 2911.381604] sd 6:0:0:0: [sdb] 123527168 512-byte logical blocks: (63.2 GB/58.9 GiB)
[ 2911.381957] sd 6:0:0:0: [sdb] Write Protect is off
[ 2911.381964] sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 2911.384411] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA
[ 2911.388422]  sdb:
[ 2911.390465] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[ 2911.754932] FAT-fs (sdb): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
root@dellnotebook:/home/marcel# 

Und nun?

[DeletedUserReAsG]

Und nun?

Und nun machst du, was in der von dir gepasteten Meldung geschrieben steht (ganz am Ende der Teil):

Code: Alles auswählen

[ 2911.754932] FAT-fs (sdb): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Um’s künftig zu vermeiden: Stick vor dem Abziehen aushängen – unter jedem System.

[leere8sam]

Code: Alles auswählen

root@dellnotebook:/home/marcel# fsck
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
/dev/mapper/dellnotebook--vg-root ist eingehängt.
e2fsck: Fortsetzung nicht möglich, wird abgebrochen.
root@dellnotebook:/home/marcel# 

Der USB-Stick funktioniert nun wieder im Schreib-Lese-Modus.
Vielen Dank.

[leere8sam]

Leider kann ich nun nur noch im Lese-Modus auf den Stick zugreifen. Zwischenzeitlich habe ich das Konsole-Fenster geschlossen.
Warum ist immer nur ein kurzzeitiger Zugriff im Schreib-Lese-Modus auf den USB-Stick möglich und nicht dauerhaft?
Aus irgendeinem Grund wechselt der Zugriffsmodus schnell wieder in den Lese-Modus auf den Stick. Das Problem haben wir leide noch nicht gelöst.

[MSfree]

Probier es mal so:

Code: Alles auswählen

su -
umount /dev/sdb
fsck /dev/sdb

Das Dateisystem auf dem Stick ist VFAT. Nutzt du den Stick zum Datenaustausch mit einem Windowsrechner? Wenn ja, dann muß dort der Stick mit "sicher auswerfen" ausgehängt werden, bevor man ihn abzieht. Sonst ist das Dateisystem gleich wieder kaputt.

[leere8sam]

Danke für die Hilfe.
Ja, ich nutze den Stick auch unter Win10 und ja, wenn Win10 abstürzt und/oder ich den USB-Stick dort nicht korrekt abziehe oder er von Win10 "repariert" wird, das könnte die Ursache der Probleme sein. Denn früher funktionierte es mal einwandfrei.
Zudem habe ich noch einen Ordner auf dem Stick, der ganz komisch entstanden ist (Name "xxyyzz...pdf") und den ich einfach nicht löschen kann (auch auf keinem anderen System). Dieser Ordner könnte auch noch für Probleme verantwortlich sein. Der Ordner ist versehentlich entstanden, als ich ein PDF erzeugen oder etwas verschlüsseln wollte ...
So nun die Ausgabe:

Code: Alles auswählen

root@dellnotebook:~# umount /dev/sdb
root@dellnotebook:~# fsck /dev/sdb
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Reserved field in VFAT long filename slot is not 0 (but 0xb4).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x0bc6).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "嘤䷗쬘⒈皜ÿ﫫:DfI恵וֹꑩ".
  (Start may have been overwritten by «╘ÉH⌠ⁿ.Å╫)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name «╘ÉH⌠ⁿ.Å╫)
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x14).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x5a7a).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "ᓣ톌킜偺ᒣꊸ貐܊兊⟅楐".
  (Start may have been overwritten by HuRg.dRè)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name HuRg.dRè)
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x23).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0xa623).
1: Fix.
2: Leave it.
? 1
Wrong checksum for long file name "됍蛡鴊㛄爎㻣砦쒃阺㒮ﮫ毩墺".
  (Short name `YrnP;*╝.ä║ may have changed without updating the long name)
1: Delete LFN
2: Leave it as it is.
3: Fix checksum (attaches to short name `YrnP;*╝.ä║)
? 1
Long filename fragment "ｵ฀䠴⿴:DW3몺侌ꑰᵲ䢆:Den㶺" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0xed).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x27c7).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "⟸榥ⅾ풷㕯╠:DtI뛭ﰍ⑭㧮ת옿".
  (Start may have been overwritten by  )
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name  )
? 1
Long filename fragment "酊䨩⎤ꤝᑇʙ蚗క涇὆э劓" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Long filename fragment "㚦擙ꒌ⪃乎꽴먻Ⱦ饻隣" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0xc6).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x697f).
1: Fix.
2: Leave it.
? 1
Unfinished long file name ":DdL䯑ᤁ錫擳펦翢疊㨟㭝귁︌
  (Start may have been overwritten by »╡ÄO#≈~.ƒ\w)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name »╡ÄO#≈~.ƒ\w)
? 1
Reserved field in VFAT long filename slot is not 0 (but 0xa6).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x9e54).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "ḁ酧뚝肎鱤Ͷ縙ꅡ델轖:DjR뀻".
  (Start may have been overwritten by íφWx.£⌐Σ)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name íφWx.£⌐Σ)
? 1
Long filename fragment "됍㎒醁㧽꧶ĵ蛏䢼阙棋雔᳀" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x4a).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x4b73).
1: Fix.
2: Leave it.
? 1
Unfinished long file name ":D+T쮘厓펜ᣅ⊤ྊ耔ᭊ਴".
  (Start may have been overwritten by═▒ú╡&Ni.yñ)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name═▒ú╡&Ni.yñ)
? 1
Long filename fragment "⢊䧩骻䨏㑧贵췢籡暚" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Unexpected long filename sequence number (0 vs. expected -1).
1: Delete LFN
2: Leave it as it is (and ignore LFN so far)
? 1
Reserved field in VFAT long filename slot is not 0 (but 0xe9).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x2371).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "峀ḩ㾹窇翳쏻㇞胰銲엛ꬪ첤槟".
  (Start may have been overwritten by D`Bτ棣.)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name D`Bτ棣.)
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x1c).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x3cad).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "﬌듦騣⌹䛪݁
  (Start may have been overwritten by üiTqE┴.ª;à)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name üiTqE┴.ª;à)
? 1
Long filename fragment "揥㫦傖掸㲷믢螏:DpG☝䯚ﱸ" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x23).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0xa876).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "씙娧䨳ꀈ⤊䱵訳䙑㑁乙".
  (Start may have been overwritten by ₧Öñ∙ )
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name ₧Öñ∙ )
? 1
Long filename fragment "躃ⅹ땏㰙딚찑ࠐ욈윀掌" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Long filename fragment "猜⓵껷혦㨴푕᮸눊ò" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Long filename fragment "侐礝ᗏ싇꾕捴糨㧩ÿ痈쟠ﲉ" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x51).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0xe0a9).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "흱ꎎ贈謏浴痗筱猳㩥틊撴ϯ㠸".
  (Start may have been overwritten by #'╘t«
o.|JÆ)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name #'╘t«
o.|JÆ)
? 1
Long filename fragment "㐐뫒᫇컲ç⼚㗍啻彦" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0xf0).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0xadef).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "赽ᢎ섃ᷧ꽸纍쮒땛⼈擑葉".
  (Start may have been overwritten by 1((
                                         )      ò)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name 1((
                                                                       )        ò)
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x8e).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x71e5).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "ĝԽ罐:Dw9栗꒵筛媙鬨糊쮒⪷".
  (Start may have been overwritten by >a╦╓╡5».▒h:)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name >a╦╓╡5».▒h:)
? 1
Long filename fragment "ౢ왜䄉溷:Drm⭽剗곔鯴밇:DwEἄ" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x5a).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x3fc7).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "穐㌂䫏䗲뻑ᛗ:DoOⲹ匶㸈".
  (Start may have been overwritten by Θδ╙w=EP.O≡τ)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name Θδ╙w=EP.O≡τ)
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x4a).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x08cd).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "ꎉ뜍焽鶞窺蒷:Dh5ˋ앞抸솭".
  (Start may have been overwritten by ▒╔∙ç\≡▐╜.ìtz)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name ▒╔∙ç\≡▐╜.ìtz)
? 1
Long filename fragment "Ⲩ읨㍺띉䢽ꙉ됎勼㓣⊙銓䨇儱" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
1: Delete fragment
2: Leave it as it is.
3: Set start bit
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x2d).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0x3e76).
1: Fix.
2: Leave it.
? 1
Unfinished long file name "丯禆摭ູ玍洔ᇄ㋪画碧쏟︕".
  (Start may have been overwritten by ìm!╣╖ü#u.i)
1: Delete LFN
2: Leave it as it is.
3: Fix numbering (truncates long name and attaches it to short name ìm!╣╖ü#u.i)
? 
1
Invalid input.
? 1
Reserved field in VFAT long filename slot is not 0 (but 0x22).
1: Fix.
2: Leave it.
? 1
Start cluster field in VFAT long filename slot is not 0 (but 0xcef1).
1: Fix.
2: Leave it.

An dieser Stelle habe ich das Programm abgebrochen.
Was meint ihr dazu?

[MSfree]

Ja, ich nutze den Stick auch unter Win10 und ja, wenn Win10 abstürzt und/oder ich den USB-Stick dort nicht korrekt abziehe oder er von Win10 "repariert" wird, das könnte die Ursache der Probleme sein. Denn früher funktionierte es mal einwandfrei.

Das mit dem "sicher entfernen" gilt unter Windows schon seit man dort USB-Sticks einhängen kann, also mindestens seit Win98. Das es früher mal einwandfrei funktioneirt hat, war ganz sicher nicht der Fall. Daß es nie zu Fehlern gekommen ist, war reines Glück.

Was meint ihr dazu?

Wenn dir die Reperatur mit Linux zu gewagt ist, kannst du den Stick auch unter Win10 reparieren, indem du eine "DOS"-Box öffnest, also cmd.exe startest, und dort chdsk x: eingibts ( x: ist durch den Laufwerksbuchstanben des Sticks zu ersetzen).

[DeletedUserReAsG]

Was meint ihr dazu?

Ich würd’s formatieren, und gut. So eine Vielzahl an Fehlern lässt erwarten, dass zumindest teilweise Datenmüll vorhanden ist.

[guennid]

gilt unter Windows schon seit man dort USB-Sticks einhängen kann

Nach meiner Erinnerung konnte „man“ das dort noch nie und kann es auch jetzt nicht. Nur windows kann/darf/macht das. Womit die Vermutung nahe liegt, dass win sich auch um das Aushängen kümmert, was es dann aber nicht mehr tut (wie auch?). Die Ergebnisse sind in diesem Thread zu besichtigen.

Grüße, Günther

[MSfree]

Nach meiner Erinnerung konnte „man“ das dort noch nie und kann es auch jetzt nicht.

Oh doch, in der Taskleiste unten rechts gibt es ein Icon, mit dem man USB-Geräte "sicher aushängen" kann, und zwar schon seit Win98. Wenn die Leute mal ihre Augen dorthin gerichtet hätten, wären in den letzten 20 Jahren deutlich weniger Dateisystem kaputt gegangen, durch unüberlegtes abziehen. Ich kann auch schon lange nicht mehr zählen, wie oft ich diesen Tip von der c't bis zur Computerbild geschätzt mindestensa alle 2 Monate, gelesen habe, aber scheinbar gibt es immer noch Leute, denen das unbekannt ist.

[guennid]

Oh doch, in der Taskleiste unten rechts gibt es ein Icon, mit dem man USB-Geräte "sicher aushängen" kann, und zwar schon seit Win98.

Ich sprach vom Einhängen, nicht vom Aushängen und welche Folgen das dann hat, das gar nicht (selbst) Einhängen können.

[DeletedUserReAsG]

Das war ja das Problem bei Windows: ein Automounter hat’s stillschweigend eingehängt und keiner hat den Usern erzählt, dass der nicht hellsehen kann, und die Datenträger daher manuell ausgehängt werden müssen. Mittlerweile schreibt Win die Daten wohl so schnell wie möglich weg (ohne jedoch zu blockieren oder den User zu informieren). Das vermeidet Datensalat, solange der Stick nicht direkt nach ’nem Schreibvorgang abgezogen wird.

[MSfree]

Ich sprach vom Einhängen

Der Datensalat entsteht ja, wenn man den Stick abzieht, bevor alle Daten und Dateisystemstrukturen geschrieben wurden. Insofern ist das Einhängen ein ungefährlicher Vorgang und Windows warnt sogar, wenn es das Dateisystem als defekt erkennt und bietet eine Reperatur an. Allerdings ist die Defekterkennung unter Windows nicht besonders zuverlässig.

Mittlerweile schreibt Win die Daten wohl so schnell wie möglich weg (ohne jedoch zu blockieren oder den User zu informieren). Das vermeidet Datensalat, solange der Stick nicht direkt nach ’nem Schreibvorgang abgezogen wird.

Das funktioniert aber nur zuverlässig, wenn das Dateisystem (V)FAT ist. Mit NTFS ist das längst nicht so unkompliziert.

[leere8sam]

Vielen Dank!
Die Reparatur mit Linux ist mir nicht zu gewagt, nur hatte ich den Eindruck, dass "fsck" nicht mehr aufhört mit dem Fragen. Gibt es zufällig dazu eine Abkürzung, in der Form, dass "fsck" ohne Nachfragen den USB-Stick repariert?

Kann mir bitte jemand die Befehle nennen, um den Stick alternativ neu zu formatieren.
Ich würde dann alternativ die Daten sichern, den Stick neu formatieren und im besten Fall danach wieder einwandfrei nutzen können.
Danke!

[DeletedUserReAsG]

Gibt es zufällig dazu eine Abkürzung, in der Form, dass "fsck" ohne Nachfragen den USB-Stick repariert?

Code: Alles auswählen

[…]
-a       automatically repair the filesystem
[…]
-y       same as -a, for compat with other *fsck

Kann mir bitte jemand die Befehle nennen, um den Stick alternativ neu zu formatieren.

mkfs.vfat /dev/richtigesDevice

Edit/Ergänzung/OT: du solltest dir auch mal ein paar Grundlagen anlesen. Wichtig wäre z.B. zu wissen, dass nahezu jedes Programm dokumentiert ist: Kurzhilfe via command --help, lange Version via man command. Ansonsten wirst du dich bei Linuxssystemen nur unnötig quälen, bzw. einen großen Teil der Möglichkeiten ungenutzt lassen. Glaub mal nicht, dass hier (oder woanders) immer jemand ist, der dir so grundlegenden Kram vorgekaut serviert.

[guennid]

Das war ja das Problem bei Windows: ein Automounter hat’s stillschweigend eingehängt und keiner hat den Usern erzählt, dass der nicht hellsehen kann, und die Datenträger daher manuell ausgehängt werden müssen.

Das war's! Und deswegen muss sich auch MSfree nicht wundern, dass so viele WIn-Benutzer auch heute noch nicht wissen, was eigentlich Sache ist. Hoffentlich wissen's die Linux-Nutzer, denn da passiert ja mittlerweile standardmäßig genau das Gleiche. Kann ich aber nicht wirklich beurteilen, da ich kein Standard-System benutze.

[wanne]

Das funktioniert aber nur zuverlässig, wenn das Dateisystem (V)FAT ist. Mit NTFS ist das längst nicht so unkompliziert.

Das ist ein bisschen ein zweischneidiges Pfert. NTFS lässt sich auch um Größenordnungen besser reparieren und vor allem erkennt es ob es zuverlässig ob es abgezogen wurde ohne ausgeworfen/ungemounted worden zu sein. Entsprechend robuster ist es gegen Probleme.
Ich gehe fest davon aus, das im hiesigen Fall eine Menge Dateien kaputt gegangen sind. (Ob das der der Poster Merken wird ist natürlich eine andere frage. Man kann erstaunlich viele Daten kaputt machen bevor der User ohne Checksummen was merkt.)
Das wäre mit NTFS vermutlich so nicht passiert. Ich nutze wo ich kann immer btrfs-dup oder wenigstens NTFS oder ext3/4 auf Sticks, weil es eben ein deutlich robuster die Daten hällt.