Komunikat, że dysk jest zabezpieczony przed zapisem, zwykle nie oznacza jednej, prostej usterki. Czasem winny jest fizyczny przełącznik, czasem system plików został przełączony w tryb tylko do odczytu po błędzie, a czasem nośnik sam ogranicza zapis, bo zaczyna się zużywać. Poniżej pokazuję, jak rozpoznać przyczynę, które kroki w Linuksie są bezpieczne i kiedy lepiej od razu ratować dane niż walczyć o szybkie odblokowanie.
Najpierw ustal, czy blokada dotyczy urządzenia, partycji czy uprawnień
- Najczęściej problem leży w trybie tylko do odczytu, a nie w całkowitym uszkodzeniu nośnika.
- W Linuksie pierwsze trzy testy to `lsblk`, `findmnt` i logi jądra.
- Jeśli system plików zgłasza błędy, nie wymuszam zapisu przed sprawdzeniem integralności.
- Gdy pendrive lub SSD sam przechodzi w tryb tylko do odczytu, formatowanie może nie pomóc.
Co dokładnie oznacza tryb tylko do odczytu
W praktyce rozróżniam dwa scenariusze: blokadę na poziomie urządzenia i blokadę na poziomie systemu plików. Z perspektywy użytkownika oba potrafią wyglądać podobnie, ale technicznie to zupełnie inne stany i naprawia się je inaczej.
Poziom urządzenia
Tu jądro systemu traktuje cały nośnik jako zapisowo zablokowany. W `lsblk` zobaczysz zwykle `RO=1`, a każda próba zapisu kończy się komunikatem odrzucenia operacji. Taki stan bywa ustawiony ręcznie, ale częściej pojawia się dlatego, że kontroler nośnika wykrył problem i sam ograniczył zapis, żeby nie pogorszyć sytuacji.
Przeczytaj również: NTFS czy FAT32 - co wybrać dla pendrive'a i dysku? Poznaj różnice
Poziom systemu plików
To częstszy przypadek na Linuksie. Partycja jest zamontowana jako `ro`, czyli tylko do odczytu, bo system zauważył błędy albo nie ufa już spójności danych. Wtedy urządzenie nie musi być fizycznie zablokowane, ale zapis na tym punkcie montowania i tak nie przejdzie. Na ext4 samo `ro` nie zawsze oznacza absolutny brak zapisów, bo jądro może odtworzyć dziennik; jeśli zależy mi na maksymalnym ograniczeniu zmian, wybieram montowanie z `ro,noload`.
To rozróżnienie jest ważne, bo inne narzędzia naprawiają flagę urządzenia, a inne błędy systemu plików. Kiedy to mam już jasne, przechodzę do najczęstszych przyczyn, które widzę w praktyce.
Najczęstsze przyczyny, które widzę w praktyce
| Przyczyna | Jak to zwykle wygląda | Co robię w pierwszej kolejności |
|---|---|---|
| Przełącznik blokady na karcie SD lub adapterze | Zapisu nie da się wykonać od razu po podłączeniu, a problem dotyczy głównie kart i czytników | Sprawdzam mechaniczny suwak i testuję kartę w innym adapterze |
| System plików po błędzie został zamontowany jako tylko do odczytu | Kopiowanie jeszcze działa, ale zapis już nie, a w logach są błędy typu `EXT4-fs error` | Odmontowuję partycję i przygotowuję naprawę `fsck` |
| Brak uprawnień użytkownika | Pojawia się `Permission denied`, ale problem znika po `sudo` albo dla innego konta | Sprawdzam właściciela, grupę i uprawnienia katalogu |
| Zużyty pendrive, SSD albo karta pamięci | Nośnik zwalnia, znika z systemu, przestaje być stabilny albo sam przechodzi w tryb tylko do odczytu | Najpierw kopiuję dane, dopiero potem analizuję stan nośnika |
| Wpis w `fstab` albo ręczne montowanie z opcją `ro` | Problem wraca po restarcie albo po ponownym podłączeniu | Sprawdzam konfigurację montowania, nie sam nośnik |
Właśnie tutaj najłatwiej popełnić błąd: wiele osób zakłada od razu awarię sprzętu, a w rzeczywistości winny bywa zwykły tryb montowania albo uprawnienia katalogu. Żeby nie zgadywać, wolę najpierw zebrać twarde dane z systemu.
Jak sprawdzam źródło problemu w Linuksie
Zaczynam od prostego zestawu poleceń, bo one najszybciej pokazują, czy mam do czynienia z blokadą urządzenia, partycji czy tylko pojedynczego punktu montowania.
lsblk -o NAME,RO,TYPE,SIZE,FSTYPE,MOUNTPOINTS
findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/usb
dmesg -T | tail -n 80
journalctl -k -b | tail -n 80
sudo smartctl -a /dev/sdXNa co patrzę w wyniku? Przede wszystkim na `RO=1`, opcję `ro` w montowaniu oraz komunikaty typu `I/O error`, `Buffer I/O error`, `blk_update_request`, `EXT4-fs error` albo wzmianki o ponownym zamontowaniu w trybie tylko do odczytu. Jeśli takie wpisy się pojawiają, to już nie jest zwykły problem z uprawnieniami. W przypadku dysków HDD i SSD dokładam jeszcze SMART, bo on często zdradza, czy nośnik zaczyna się sypać.
Jeżeli logi są czyste, a problem wygląda jak zwykła blokada programowa, zwykle da się go odkręcić bez większej ingerencji. Wtedy przechodzę do bezpiecznych działań naprawczych.
Co robię, gdy blokada jest tylko programowa
Najpierw sprawdzam, czy partycja nie jest po prostu zamontowana z opcją `ro`. Jeśli logi nie pokazują błędów sprzętowych, mogę spróbować ponownego montowania w trybie zapisu:
sudo mount -o remount,rw /mnt/usbJeśli to zadziała, problem był najpewniej po stronie montowania, a nie samego nośnika. Gdy jednak blokada dotyczy całego urządzenia, czasem pomaga sprawdzenie flagi blokady na poziomie bloku:
sudo blockdev --getro /dev/sdX
sudo blockdev --setrw /dev/sdXNie traktuję tego jako uniwersalnego lekarstwa. To działa tylko wtedy, gdy nośnik i sterownik faktycznie pozwalają na zmianę stanu, a w przypadku części pamięci USB albo kart SD ten krok nic nie da. Z kolei `hdparm -r0` bywa pomocny na niektórych urządzeniach ATA/SATA, ale na USB często nie rozwiązuje sprawy.
Jeśli potrzebuję tylko obejrzeć zawartość ext4 i nie chcę ryzykować dodatkowych zapisów, wolę montować z `ro,noload`, a nie na siłę wymuszać zapis. To drobny szczegół, ale w diagnostyce potrafi zrobić różnicę. Gdy problem wraca mimo takich prób, sprawdzam już integralność systemu plików.
Kiedy fsck jest właściwym ruchem
To jest moment, w którym wiele osób próbuje najgorszej możliwej rzeczy, czyli zapisów na uszkodzonej partycji. Ja robię odwrotnie: najpierw odmontowuję nośnik, a dopiero potem sprawdzam i naprawiam system plików.
sudo umount /dev/sdXN
sudo fsck -f /dev/sdXNW przypadku `ext2`, `ext3` i `ext4` używam `fsck` albo `e2fsck`. Dla `XFS` właściwym narzędziem jest `xfs_repair`, a przy `Btrfs` podchodzę ostrożnie, bo naprawa bywa bardziej złożona i łatwo zrobić sobie problem większy niż wyjściowy. Jeśli chodzi o główną partycję systemową, uruchamiam wszystko z live USB albo z trybu ratunkowego, a nie z działającego systemu.
Naprawa sens ma wtedy, gdy problem wynika z błędów logicznych: niespodziewanego odpięcia nośnika, resetu zasilania albo błędnego odmontowania. Jeśli jednak w logach pojawiają się powtarzalne błędy wejścia-wyjścia, a urządzenie zaczyna znikać z systemu, traktuję to już jako coś poważniejszego.
Jak odróżniam awarię nośnika od zwykłego błędu konfiguracji
Tu patrzę na zestaw objawów, a nie na jeden komunikat. Sam napis o ochronie przed zapisem nie mówi jeszcze wszystkiego. O awarii nośnika myślę mocniej, gdy widzę kilka z tych sygnałów naraz:
- urządzenie pojawia się i znika w `lsblk` albo zmienia nazwę po ponownym podłączeniu,
- pojemność nośnika nagle wygląda inaczej niż wcześniej,
- w logach powtarzają się `I/O error`, `reset` lub błędy kontrolera USB,
- SMART pokazuje błędy odczytu, realokacje albo stan ostrzegawczy,
- pendrive, karta SD lub SSD sam przechodzi w tryb tylko do odczytu, żeby chronić dane.
To ostatnie zdarza się częściej, niż wielu osobom się wydaje. Kontroler w pamięciach flash potrafi zablokować zapis celowo, gdy wykryje zużycie komórek pamięci lub problem z mapowaniem bloków. Z zewnątrz wygląda to jak zwykła blokada, ale w praktyce jest to sygnał, że nośnik nie chce już współpracować w pełnym zakresie.
Jeżeli te objawy się powtarzają, nie próbuję ratować sytuacji formatowaniem. Najpierw zabezpieczam dane, a dopiero potem decyduję, czy nośnik da się jeszcze używać.
Zanim sformatujesz nośnik, zrób jedną rzecz po kolei
Jeśli pliki są ważniejsze niż szybka naprawa, zaczynam od kopii. To najlepsza decyzja, jaką można podjąć przy niestabilnym dysku, bo każda kolejna próba zapisu albo intensywnego odczytu może pogorszyć stan nośnika.
- Jeśli da się odczytywać pliki, kopiuję najpierw najważniejsze katalogi na inny dysk.
- Jeśli odczyt przerywa, robię obraz nośnika narzędziem typu `ddrescue`, zamiast męczyć oryginał.
- Pracuję potem na kopii, a nie na uszkodzonym urządzeniu.
- Formatowanie zostawiam na koniec, kiedy dane są już bezpieczne albo nie mają wartości.
To podejście jest po prostu rozsądne: najpierw minimalizuję ryzyko utraty danych, dopiero potem naprawiam, czyszczę albo wymieniam nośnik. Jeśli komunikat wraca natychmiast po ponownym podłączeniu, traktuję to jako sygnał ostrzegawczy, a nie drobną usterkę do „przeklikania”.
