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 문제를 확인하는 순서
실무에서는 다음 순서대로 점검하는 것이 가장 효율적입니다.
mount확인dmesg확인journalctl -k확인smartctl확인df -h확인fsck실행- EXT4/XFS 로그 확인
- Read-Write 재마운트 시도
- RAID 상태 확인
- 백업 및 디스크 교체 검토
이 순서대로 진행하면 대부분의 원인을 빠르게 파악할 수 있습니다.
오류를 예방하는 방법
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 등을 통해 근본 원인을 먼저 확인해야 합니다. 특히 디스크 이상이 확인되면 즉시 백업을 수행하고 저장 장치 교체를 준비하는 것이 안전한 운영의 핵심입니다.