Lỗi này là gì
Bạn cố ghi file hoặc tạo thư mục và nhận được thông báo:
touch: cannot touch '/var/log/app.log': Read-only file system
Hoặc các biến thể tương tự:
mkdir: cannot create directory '/etc/myapp': Read-only file system
bash: /tmp/script.sh: Read-only file system
cp: cannot create regular file '/usr/local/bin/mytool': Read-only file system
Filesystem được mount tại đường dẫn đó đã chuyển sang chế độ chỉ đọc — có thể do chủ ý, hoặc do kernel buộc phải làm vậy sau khi phát hiện lỗi.
Nguyên nhân gốc rễ
Linux remount filesystem thành chỉ đọc trong một số tình huống chính:
- Lỗi ổ đĩa hoặc filesystem — khi kernel gặp lỗi I/O hoặc journal không nhất quán, nó tự động chuyển filesystem sang chỉ đọc để ngăn dữ liệu bị hỏng.
- Mount chỉ đọc tường minh — filesystem được mount với tùy chọn
ro, trong/etc/fstabhoặc qua lệnhmountthủ công. - Hỏng phần cứng — ổ đĩa sắp hỏng, cáp SATA/SAS kém chất lượng, hoặc mảng RAID bị suy giảm đều có thể gây ra điều này.
- Giới hạn từ container hoặc VM — một số cấu hình Docker và Kubernetes cố tình mount filesystem của host ở chế độ chỉ đọc.
Hãy chú ý đặc biệt đến tình huống đầu tiên. Một lần remount do kernel cưỡng bức không chỉ gây phiền toái — đó là cảnh báo rằng ổ đĩa của bạn có thể đang gặp sự cố nghiêm trọng. Remount lại chế độ ghi mà không kiểm tra nguyên nhân trước có thể khiến dữ liệu bị hỏng nặng hơn.
Bước 1: Xác định filesystem nào bị ảnh hưởng
Tìm thiết bị nào đứng sau đường dẫn đang gây lỗi:
df -h /var/log/app.log
Ví dụ kết quả:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 12G 36G 25% /
Kiểm tra xem thiết bị đó có đang được mount ở chế độ chỉ đọc không:
mount | grep /dev/sda1
Cờ (ro, chính là dấu hiệu nhận biết:
/dev/sda1 on / type ext4 (ro,relatime,errors=remount-ro)
Hoặc dùng cách thay thế:
cat /proc/mounts | grep ' / '
Bước 2: Kiểm tra log kernel để tìm nguyên nhân
Đừng vội sửa ngay. Trước tiên, hãy tìm hiểu tại sao nó chuyển sang chỉ đọc:
dmesg | grep -i 'error\|read-only\|remount\|EXT4\|XFS' | tail -30
Hoặc kiểm tra system journal:
journalctl -k --no-pager | grep -i 'remount\|error\|I/O error' | tail -20
Thấy các thông báo như EXT4-fs error, I/O error, hoặc remounting filesystem read-only? Điều đó có nghĩa là lỗi ổ đĩa đã kích hoạt điều này. Hãy chạy kiểm tra filesystem trước khi làm bất cứ điều gì khác.
Log sạch, không có thông báo lỗi? Filesystem có thể đã được mount ở chế độ chỉ đọc một cách có chủ ý. Bỏ qua và chuyển thẳng đến bước remount.
Bước 3: Kiểm tra sức khỏe ổ đĩa
Khi dmesg hiển thị lỗi I/O, hãy lấy dữ liệu SMART của ổ đĩa:
sudo apt install smartmontools # Ubuntu/Debian
sudo yum install smartmontools # CentOS/RHEL
sudo smartctl -a /dev/sda
Kết quả SMART overall-health self-assessment test result: FAILED là dấu hiệu nguy hiểm cần xử lý ngay. Nhưng ngay cả khi kết quả qua được, vẫn cần kiểm tra bảng thuộc tính để tìm các giá trị khác 0 trong Reallocated_Sector_Ct, Current_Pending_Sector, hoặc Offline_Uncorrectable. Chỉ 5 sector được tái phân bổ cũng đáng lo ngại.
Ổ đĩa hỏng phải được thay thế. Remount lại chế độ ghi trên phần cứng đang hấp hối là canh bạc mà bạn không nên thử.
Cách sửa A: Remount filesystem sang chế độ ghi (sửa nhanh)
Sức khỏe ổ đĩa ổn, hoặc bạn chỉ cần quyền ghi tạm thời? Hãy remount:
sudo mount -o remount,rw /
Thay / bằng mount point thực tế của đường dẫn — /var, /home, tùy trường hợp:
sudo mount -o remount,rw /var
Xác nhận đã thành công:
mount | grep '/var'
# Phải hiển thị (rw, thay vì (ro,
Sau đó thử lại lệnh ban đầu:
touch /var/log/app.log
echo $? # 0 nghĩa là thành công
Cách sửa B: Chạy kiểm tra filesystem (khi có lỗi ổ đĩa)
Các lần remount do kernel cưỡng bức yêu cầu chạy fsck trên filesystem đã được unmount. Với các phân vùng không phải root, điều này khá đơn giản:
sudo umount /dev/sdb1
sudo fsck -f /dev/sdb1
Filesystem root (/) phức tạp hơn — bạn không thể unmount nó khi hệ thống đang chạy. Cách tốt nhất là khởi động từ USB live hoặc chế độ rescue và chạy fsck từ đó:
fsck -y /dev/sda1
Cờ -y tự động chấp nhận tất cả các bản sửa. Sau khi fsck hoàn thành, khởi động lại và filesystem sẽ khởi động ở chế độ ghi.
Trên các hệ thống cũ không có live media, bạn có thể lên lịch kiểm tra vào lần khởi động tiếp theo:
sudo touch /forcefsck
Cách sửa C: Sửa fstab nếu filesystem được mount chỉ đọc có chủ ý
Mở /etc/fstab và tìm tùy chọn ro:
cat /etc/fstab
Một entry như thế này chính là thủ phạm:
/dev/sda1 / ext4 ro,errors=remount-ro 0 1
Chỉnh sửa file và thay ro thành rw:
sudo nano /etc/fstab
# Thay: ro,errors=remount-ro
# Thành: rw,errors=remount-ro
Áp dụng thay đổi mà không cần khởi động lại:
sudo mount -o remount,rw /
Luôn kiểm tra fstab trước khi khởi động lại — một lỗi cú pháp ở đây có thể khiến hệ thống không thể khởi động:
sudo findmnt --verify
Cách sửa D: Kiểm tra sự cố phần cứng
Filesystem vẫn chuyển sang chỉ đọc sau khi remount? Bản thân ổ đĩa có thể là thủ phạm thực sự:
# Quét bad block (chậm nhưng kỹ)
sudo badblocks -v /dev/sda
# Kiểm tra số lỗi SMART trực tiếp
sudo smartctl -A /dev/sda | grep -E 'Reallocated|Pending|Uncorrectable'
Bất kỳ giá trị khác 0 nào trong ba cột đó đều là dấu hiệu cảnh báo. Reallocated_Sector_Ct trên 10 thường có nghĩa là ổ đĩa đang đếm ngược thời gian. Hãy sao lưu dữ liệu ngay bây giờ và lên kế hoạch thay thế.
Xác nhận
Sau bất kỳ bản sửa nào, hãy xác nhận filesystem thực sự có thể ghi được:
# Kiểm tra cờ mount
mount | grep rw
# Kiểm tra ghi
touch /var/log/app.log && echo 'ghi OK' || echo 'vẫn chỉ đọc'
# Kiểm tra lỗi kernel mới
dmesg | tail -10
Nếu bạn đã sửa fstab, hãy khởi động lại và xác nhận mount vẫn hoạt động đúng:
sudo reboot
# Sau khi khởi động lại:
mount | grep '/dev/sda1'
Phòng ngừa
- Bật giám sát SMART:
sudo systemctl enable smartd. Nó theo dõi sức khỏe ổ đĩa trong nền và có thể gửi email cho bạn trước khi ổ đĩa hỏng hoàn toàn. - Cảnh báo khi có lỗi I/O trong
dmesg— đẩy kết quả qua log aggregator hoặc thiết lập cron job tìm kiếmI/O errorvà gửi thông báo. - Giữ
errors=remount-rotrong các entry ext4 của fstab. Đây là giá trị mặc định đúng đắn — nó bảo vệ dữ liệu khi có sự cố. Chỉ cần kết hợp với giám sát để bạn thực sự nhận thấy khi nó kích hoạt. - Đặt
/var/logtrên phân vùng riêng. Như vậy, lỗi filesystem root sẽ không làm tê liệt hệ thống ghi log vào lúc tồi tệ nhất.