Linux Read-only file system 오류가 발생하는 원인과 복구 방법

Linux 서버를 운영하다 보면 정상적으로 파일을 생성하거나 수정하던 중 갑자기 Read-only file system 오류가 발생하는 경우가 있습니다. 이 오류가 발생하면 파일 생성, 삭제, 수정이 모두 불가능해지며 데이터베이스나 웹 서비스도 정상적으로 동작하지 않을 수 있습니다.

많은 관리자는 단순한 권한 문제라고 생각하지만, 실제로는 디스크 오류나 파일 시스템 손상으로 인해 Linux 커널이 파일 시스템을 보호하기 위해 읽기 전용(Read-Only)으로 변경한 경우가 많습니다.

이번 글에서는 Read-only file system 오류의 원인과 실무에서 사용하는 복구 절차를 자세히 알아보겠습니다.

Read-only file system이란 무엇인가?

Read-only file system은 현재 파일 시스템이 읽기만 가능한 상태로 변경되었다는 의미입니다.

대표적인 오류는 다음과 같습니다.

touch test.txt
touch: cannot touch 'test.txt': Read-only file system

또는

rm file.txt
rm: cannot remove 'file.txt': Read-only file system

또는

vi config.conf
E212: Can't open file for writing

운영체제가 파일 시스템을 보호하기 위해 자동으로 읽기 전용으로 전환한 경우가 많습니다.

Read-only file system 오류가 발생하는 대표적인 원인

다음과 같은 경우에 자주 발생합니다.

  • EXT4 파일 시스템 오류
  • XFS 오류
  • SSD/HDD 장애
  • 배드 섹터
  • 갑작스러운 전원 차단
  • 커널 패닉 이후 복구 실패
  • RAID 장애
  • 파일 시스템 강제 보호
  • 잘못된 마운트 옵션
  • USB 저장장치 오류

실무에서는 커널 로그를 가장 먼저 확인하는 것이 중요합니다.

1. 현재 마운트 상태 확인하기

현재 파일 시스템이 읽기 전용인지 확인합니다.

mount

또는

mount | grep " ro,"

예시

/dev/sda1 on / type ext4 (ro,relatime)

ro가 표시된다면 읽기 전용 상태입니다.

2. 커널 로그 확인하기

가장 먼저 커널 로그를 확인합니다.

dmesg | tail -100

또는

journalctl -k

다음과 같은 메시지가 있는지 확인합니다.

EXT4-fs error
Remounting filesystem read-only

이 로그가 있다면 파일 시스템 보호 기능이 동작한 것입니다.

3. 디스크 상태 확인하기

SMART 정보를 확인합니다.

smartctl -H /dev/sda

상세 정보

smartctl -a /dev/sda

다음 항목을 확인합니다.

  • Reallocated Sector Count
  • Pending Sector
  • Offline Uncorrectable
  • SMART Overall Health

이상 수치가 증가하고 있다면 디스크 교체를 검토해야 합니다.

4. 디스크 용량 확인하기

df -h

용량이 100%인 경우에도 일부 서비스에서 유사한 문제가 발생할 수 있으므로 함께 확인합니다.

5. 파일 시스템 검사하기

파일 시스템을 검사합니다.

fsck /dev/sda1

주의사항

  • 루트 파티션에서는 운영 중 실행하지 않습니다.
  • 복구 모드 또는 라이브 환경에서 실행하는 것이 안전합니다.

6. EXT4 오류 확인하기

EXT4 환경에서는 다음 로그를 확인합니다.

dmesg | grep EXT4

대표적인 로그

EXT4-fs error

반복된다면 파일 시스템 손상 가능성이 높습니다.

7. XFS 오류 확인하기

XFS를 사용하는 경우

dmesg | grep XFS

복구는

xfs_repair /dev/sdb1

운영 중인 파일 시스템에서는 언마운트 후 실행해야 합니다.

8. 읽기-쓰기(Read-Write)로 다시 마운트하기

일시적인 문제였다면 다시 마운트할 수 있습니다.

mount -o remount,rw /

하지만 디스크 오류가 계속 발생한다면 다시 Read-Only 상태가 될 수 있습니다.

9. RAID 상태 확인하기

RAID 환경이라면

cat /proc/mdstat

또는 RAID Controller 관리 도구에서 디스크 장애 여부를 확인합니다.

RAID 장애 때문에 Read-Only 상태가 되는 경우도 있습니다.

10. 백업 후 디스크 교체 검토

SMART 오류나 배드 섹터가 확인되었다면 가장 먼저 해야 할 작업은 백업입니다.

이후 다음 작업을 진행합니다.

  • SSD/HDD 교체
  • RAID 재구성
  • 파일 시스템 복구
  • 서비스 복원

디스크 이상이 확인된 상태에서 계속 운영하는 것은 매우 위험합니다.

Read-only file system 문제를 확인하는 순서

실무에서는 다음 순서대로 점검하는 것이 가장 효율적입니다.

  1. mount 확인
  2. dmesg 확인
  3. journalctl -k 확인
  4. smartctl 확인
  5. df -h 확인
  6. fsck 실행
  7. EXT4/XFS 로그 확인
  8. Read-Write 재마운트 시도
  9. RAID 상태 확인
  10. 백업 및 디스크 교체 검토

이 순서대로 진행하면 대부분의 원인을 빠르게 파악할 수 있습니다.

오류를 예방하는 방법

Read-only file system 오류는 대부분 저장 장치나 파일 시스템 문제에서 시작됩니다.

예방을 위해 다음 사항을 권장합니다.

  • SMART 상태 정기 점검
  • UPS 사용
  • 정기 백업
  • RAID 구성
  • 파일 시스템 정기 검사
  • 디스크 온도 관리
  • 커널 로그 모니터링
  • SSD 수명 관리

특히 운영 서버에서는 EXT4-fs error가 한 번이라도 발생했다면 반드시 원인을 분석하는 것이 좋습니다.

자주 묻는 질문

mount -o remount,rw만 실행하면 해결되나요?

일시적으로는 가능하지만 디스크나 파일 시스템 문제가 해결되지 않았다면 다시 읽기 전용 상태로 변경될 가능성이 높습니다.

디스크 용량이 가득 차도 Read-only가 될 수 있나요?

직접적인 원인은 아니지만, 용량 부족으로 인해 서비스 오류가 발생할 수 있으므로 함께 확인해야 합니다.

fsck는 운영 중인 서버에서 실행해도 되나요?

루트 파일 시스템에서는 권장되지 않습니다. 복구 모드나 라이브 환경에서 실행하는 것이 안전합니다.

마무리

Read-only file system 오류는 Linux 서버에서 파일 시스템 보호 기능이 동작했다는 중요한 신호입니다. 단순히 읽기-쓰기 모드로 다시 마운트하는 것보다 dmesg, journalctl, smartctl, fsck 등을 통해 근본 원인을 먼저 확인해야 합니다. 특히 디스크 이상이 확인되면 즉시 백업을 수행하고 저장 장치 교체를 준비하는 것이 안전한 운영의 핵심입니다.

댓글 남기기