To pytanie zwykle oznacza dwie różne potrzeby: chcesz rozpoznać typ partycji albo sprawdzić, czy jej struktura jest nadal spójna. W praktyce to ważne rozróżnienie, bo inne narzędzie pokaże, czy masz ext4, btrfs, xfs albo ntfs, a inne oceni, czy system plików wymaga naprawy.
Najbezpieczniej zacząć od informacji tylko do odczytu, a dopiero później przejść do testów i napraw. To podejście oszczędza czas i zmniejsza ryzyko, zwłaszcza gdy problem dotyczy partycji systemowej, dysku z ważnymi danymi albo nośnika, który już raz przeszedł w tryb tylko do odczytu.
| Polecenie | Co pokazuje | Czy wymaga sudo | Kiedy użyć |
|---|---|---|---|
lsblk -f |
Drzewo dysków, typ systemu plików, UUID, punkt montowania | Nie zawsze | Gdy chcesz szybko rozpoznać partycje i ich rolę |
df -T |
Typ systemu plików dla aktualnie zamontowanych woluminów | Zwykle nie | Gdy interesują Cię tylko zamontowane partycje |
blkid |
UUID, etykietę i typ systemu plików surowego urządzenia | Często tak | Gdy potrzebujesz potwierdzić identyfikację urządzenia |
file -s /dev/sdXN |
Sygnaturę danych na urządzeniu lub partycji | Najczęściej tak | Gdy chcesz sprawdzić nośnik bez montowania |
Jak sprawdzić system plików w Linux – identyfikacja typu partycji
Jeśli celem jest odpowiedź na pytanie „jaki to system plików?”, najlepszym punktem startowym jest lsblk -f. To polecenie pokazuje strukturę dysków w czytelnej formie: urządzenie nadrzędne, partycje podrzędne, typ systemu plików, UUID oraz miejsce montowania. Dzięki temu od razu widać, czy patrzysz na ext4, btrfs, xfs, ntfs czy np. swap.
W codziennej pracy to zwykle wygodniejsze niż samo fdisk -l, bo nie zmusza do łączenia kilku wyników w głowie. Jeśli partycja jest zamontowana, df -T pokaże jej typ razem z zajętością. To dobre narzędzie do szybkiego potwierdzenia, ale nie zobaczy wszystkiego, bo działa głównie na aktywnych punktach montowania.
blkid przydaje się wtedy, gdy chcesz sprawdzić urządzenie po UUID albo porównać wynik z wpisem w /etc/fstab. To ważne zwłaszcza przy rozruchu lub po podłączeniu kilku podobnych dysków. Z kolei file -s bada surową zawartość urządzenia i potrafi wskazać system plików nawet wtedy, gdy partycja nie jest zamontowana. To bezpieczna metoda diagnostyczna, bo niczego nie zapisuje.
Warto pamiętać o jednej praktycznej zasadzie: identyfikacja typu systemu plików nie jest jeszcze naprawą. Sam fakt, że Linux widzi partycję jako ext4, nie mówi nic o jej kondycji. Podobnie wpis NTFS nie oznacza błędu — mówi tylko, z czym masz do czynienia. Dlatego dobry proces zaczyna się od rozpoznania urządzenia, a dopiero potem przechodzi do sprawdzania spójności dysku Linux.
fsck „na wszelki wypadek” bez upewnienia się, która partycja jest właściwa. Jeśli pomylisz /dev/sda1 z /dev/sda2, ryzykujesz naprawę nie tego woluminu, który faktycznie wymaga interwencji. Najpierw identyfikacja, potem dopiero działania modyfikujące.
Jeżeli nie jesteś pewien, które urządzenie odpowiada za dane, porównaj wynik lsblk -f z df -T i blkid. Taki zestaw zwykle wystarcza, żeby bezpiecznie ustalić, która partycja jest systemowa, która domowa, a która należy do dysku zewnętrznego. To szczególnie praktyczne w komputerach z wieloma nośnikami albo w środowisku dual boot.
Sprawdzanie spójności dysku za pomocą fsck – podstawowe zasady bezpieczeństwa
fsck jest głównym narzędziem do kontroli integralności systemów plików w rodzinie Unix i Linux, ale nie jest uniwersalnym „lekiem na wszystko”. Działa dobrze dla ext2/ext3/ext4, a w innych przypadkach trzeba użyć odpowiedniego narzędzia. Dlatego przed uruchomieniem naprawy trzeba wiedzieć, co sprawdzasz i czy partycja jest odmontowana.
To najważniejsza zasada: nie uruchamiaj fsck na zamontowanej partycji. System plików w trakcie pracy może się zmieniać, więc narzędzie widzi stan niepełny albo sprzeczny. W najlepszym razie dostaniesz niepewny wynik, a w gorszym — dodatkowe uszkodzenia metadanych. Jeśli partycja jest w użyciu, najpierw ją odmontuj poleceniem umount, a dopiero potem wykonuj kontrolę.
Przed naprawą ważnych danych warto też zrobić kopię zapasową albo choćby obraz nośnika. To nie jest przesada. Jeśli system plików już sygnalizuje błędy, może to oznaczać nie tylko problem logiczny, lecz także awarię dysku lub blokadę zapisu. W takiej sytuacji każda ingerencja niesie ryzyko, więc bezpieczniej jest najpierw zabezpieczyć dane niż od razu próbować „naprawić wszystko”.
- Rozpoznaj właściwe urządzenie, np. przez
lsblk -flubblkid. - Upewnij się, że partycja nie jest zamontowana. Jeśli jest, odmontuj ją przez
umount /dev/sdXNlub po punkcie montowania. - Uruchom kontrolę odpowiednim narzędziem: dla ext2/3/4 zwykle
fsck, dla btrfs i xfs inne polecenia. - Po zakończeniu sprawdź kod wyjścia i komunikaty z terminala, zanim ponownie zamontujesz wolumin.
W praktyce ta kolejność ma znaczenie większe niż sama składnia. Jeśli system plików jest tylko źle oznaczony po niepoprawnym wyłączeniu komputera, naprawa bywa szybka. Jeśli jednak w logach widać błędy I/O, a dysk znika z systemu, to już nie jest zwykły problem logiczny. Wtedy rozsądniej przerwać działania i myśleć o kopii danych oraz diagnostyce sprzętowej.
Praktyczne parametry polecenia fsck i interpretacja wyników
Najczęściej używane opcje fsck są proste, ale warto rozumieć ich konsekwencje. -n oznacza test tylko do odczytu: narzędzie sprawdza spójność, ale niczego nie zmienia. To dobry wybór na start, gdy chcesz zobaczyć skalę problemu bez ryzyka. -p próbuje automatycznie naprawić typowe, bezpieczne błędy. -y potwierdza wszystkie zmiany, więc używaj go ostrożnie i tylko wtedy, gdy naprawdę chcesz dopuścić pełną automatyzację.
Typowe użycie wygląda tak: sudo fsck -n /dev/sdb1 przy samym sprawdzeniu, sudo fsck -p /dev/sdb1 przy łagodnej naprawie albo sudo fsck -y /dev/sdb1 przy pełnej automatyzacji. W przypadku partycji systemowej lepiej jednak wykonać to z LiveUSB niż w działającym systemie. fsck na aktywnym root może skończyć się błędami lub odmową działania.
Wynik polecenia też ma znaczenie. Najczęściej spotkasz takie kody wyjścia: 0 — brak błędów, 1 — błędy zostały poprawione, 2 — zalecany restart, 4 — błędy nie zostały naprawione, 8 — błąd operacyjny, 16 — błąd użycia, 32 — przerwanie przez użytkownika, 128 — problem biblioteczny. Nie trzeba ich znać na pamięć, ale warto umieć odróżnić „naprawiono” od „pozostały błędy”.
Jeśli fsck zwraca kod sugerujący problemy, a po ponownym montażu system plików nadal zachowuje się niestabilnie, nie zakładaj od razu, że naprawa się powiodła. Czasem narzędzie usuwa jedynie objawy. Gdy błędy wracają po kolejnym uruchomieniu, przyczyną może być uszkodzony nośnik albo zasilanie, a nie sam system plików.
Jak sprawdzić i naprawić główny system plików (root) bez utraty danych
Partycji root / nie da się bezpiecznie odmontować w działającym systemie, bo właśnie z niej korzystają procesy, biblioteki i usługi. Dlatego przy problemach z systemem startowym są dwa rozsądne wyjścia: użycie LiveCD/LiveUSB albo zaplanowanie kontroli przy następnym rozruchu. Oba rozwiązania są znacznie bezpieczniejsze niż próba wymuszenia naprawy w uruchomionym systemie.
LiveUSB ma tę zaletę, że od razu daje środowisko, w którym uszkodzona partycja nie jest aktywnie używana. Możesz wtedy zamontować ją tylko do odczytu, skopiować dane, a dopiero później uruchomić właściwe narzędzie naprawcze. To szczególnie praktyczne, gdy system nie chce się podnieść albo przechodzi w tryb awaryjny.
Jeżeli problem dotyczy woluminu innego niż root, procedura jest prostsza: odmontuj go, sprawdź i napraw. Jeśli jednak błędy dotyczą samej partycji systemowej, przyspieszanie procesu nie pomaga. W takiej sytuacji lepiej mieć spokojny plan niż próbować losowych komend z forów internetowych. Przy ważnych danych rozsądnym progiem ostrożności jest też kopia zapasowa przed każdą naprawą.
Wymuszanie fsck przy następnym restarcie systemu
Jednym ze sposobów na bezpieczne sprawdzenie root po restarcie jest wymuszenie kontroli przy starcie. Na części systemów działa utworzenie pliku /forcefsck, ale w nowoczesnych dystrybucjach opartych na systemd lepiej polegać na parametrach jądra przekazywanych przez GRUB, na przykład fsck.mode=force i fsck.repair=yes. To podejście jest bardziej przewidywalne i łatwiejsze do cofnięcia.
W praktyce oznacza to, że podczas startu system ma potraktować sprawdzanie jako obowiązkowe, a nie tylko okazjonalne. To przydatne po nagłym zaniku zasilania, twardym resecie albo wtedy, gdy logi sugerują, że system plików nie został zamknięty poprawnie. Trzeba jednak pamiętać, że samo wymuszenie kontroli nie rozwiąże problemów sprzętowych. Jeśli dysk ma błędy odczytu, naprawa może nie dojść do skutku.
Warto też nie opierać się na starych poradach w rodzaju shutdown -rF jako jedynej metody. Na nowszych systemach bywa to po prostu niekonsekwentne albo mało pewne. Bezpieczniej jest stosować metodę zgodną z używaną dystrybucją i w razie potrzeby uruchomić komputer z LiveUSB, zwłaszcza gdy start systemu już nie przebiega normalnie.
Cykliczne sprawdzanie dysków za pomocą tune2fs
Dla systemów ext2/ext3/ext4 przydatne jest tune2fs, czyli narzędzie do ustawiania parametrów kontrolnych systemu plików. Możesz dzięki niemu określić, po ilu montowaniach ma zostać wykonane sprawdzenie albo ustawić przedział czasowy między kolejnymi testami. To praktyczne rozwiązanie, jeśli chcesz ograniczyć ryzyko narastania błędów, zanim staną się uciążliwe.
Najpierw warto podejrzeć obecne ustawienia: sudo tune2fs -l /dev/sda2. Interesują Cię przede wszystkim liczba montowań i odstęp czasowy. Potem można ustawić na przykład kontrolę co 10 montowań lub co miesiąc, używając odpowiednio sudo tune2fs -c 10 /dev/sda2 oraz sudo tune2fs -i 1m /dev/sda2. Takie wartości dobrze sprawdzają się na komputerach domowych, ale w środowisku z ważnymi danymi można dobrać bardziej konserwatywny harmonogram.
To ważne ograniczenie: tune2fs nie służy do NTFS, btrfs ani xfs. Jeśli masz inny system plików, trzeba użyć narzędzi właściwych dla jego typu. Właśnie dlatego najpierw sprawdza się identyfikację partycji, a dopiero potem planuje testy. Bez tej kolejności łatwo uruchomić właściwe polecenie na niewłaściwym woluminie.
System plików wyłącznie do odczytu – jak rozwiązać ten problem
Tryb read-only nie zawsze oznacza to samo. Czasem Linux przełącza system plików tylko do odczytu, bo wykrył błędy i chce chronić dane przed dalszym zapisem. Innym razem problem wynika z NTFS po Windowsie, zwłaszcza gdy włączony był Fast Startup albo hibernacja. Zdarza się też, że przyczyną są błędy sprzętowe, które system widzi jako powtarzające się problemy z I/O.
W pierwszej kolejności warto sprawdzić logi, na przykład przez dmesg lub journalctl -k -b. Jeśli widać tam błędy zapisu, system plików prawdopodobnie przeszedł w tryb ochronny nie bez powodu. W takiej sytuacji samo ponowne zamontowanie z opcją rw może się nie udać albo zadziała tylko chwilowo.
Gdy jednak system plików jest zdrowy, a Linux tylko tymczasowo zamontował go jako tylko do odczytu, można spróbować bezpiecznej zmiany: sudo mount -o remount,rw /punkt/montowania. To rozwiązanie dotyczy już zamontowanego woluminu i nie naprawia błędów strukturalnych, ale potrafi przywrócić zapis po prostym problemie z montowaniem. Jeśli polecenie kończy się błędem, nie wymuszaj go wielokrotnie — najpierw ustal przyczynę.
W przypadku NTFS pod Linuksem pomocne bywa ntfsfix, ale trzeba jasno powiedzieć, czego to narzędzie nie robi. ntfsfix nie zastępuje pełnej naprawy w Windowsie. Ono zwykle porządkuje podstawowe problemy, ustawia wolumin do sprawdzenia i pomaga odzyskać dostęp, ale ostateczną kontrolę nadal powinien wykonać system Windows przez chkdsk. Jeśli partycja była hibernowana albo Windows nie został poprawnie zamknięty, najpierw wyłącz Fast Startup i dopiero potem uruchom pełną naprawę po stronie Windows.
W przypadku btrfs i xfs procedura jest inna. Na btrfs przy zamontowanym woluminie sens ma btrfs scrub, który sprawdza sumy kontrolne i spójność odczytu. XFS z kolei naprawia się narzędziem xfs_repair, ale na odmontowanej partycji, najlepiej z LiveUSB. To kolejny powód, dla którego nie warto traktować fsck jak uniwersalnej odpowiedzi na każdy komunikat o błędzie.
Jeśli system plików przechodzi w read-only bez wyraźnego powodu, a objaw wraca po restarcie, traktuj to jako sygnał ostrzegawczy. To może być tylko problem logiczny, ale równie dobrze początek większej awarii nośnika. W takiej sytuacji najpierw skopiuj dane, potem diagnozuj dalej. Przy ważnych plikach sensowniejsze jest zachowanie ostrożności niż szybka, ale ryzykowna naprawa.
W praktyce najlepszy schemat jest prosty: najpierw rozpoznanie typu partycji, potem bezpieczna kontrola spójności, a dopiero na końcu naprawa odpowiednim narzędziem. Dla ext4 użyjesz fsck i tune2fs, dla NTFS ntfsfix plus kontrola w Windowsie, a dla btrfs lub xfs innych poleceń. Taka kolejność daje większą kontrolę nad ryzykiem i pozwala uniknąć przypadkowych działań.
Jeżeli chcesz podejść do problemu rozsądnie, zacznij od lsblk -f, sprawdź montowanie, zabezpiecz dane i dopiero później wybierz narzędzie naprawcze. To najbezpieczniejsza odpowiedź na pytanie, jak sprawdzić system plików Linux w praktyce — bez zgadywania, bez pośpiechu i bez narażania ważnych plików.