Cảnh báo Production lúc 2 giờ sángQuá trình triển khai của bạn đã thành công, các bước kiểm tra sức khỏe (health checks) đã vượt qua và cuối cùng bạn cũng gập máy tính lại. Mười phút sau, các cảnh báo giám sát bắt đầu reo vang. Bạn kiểm tra log và thấy các container của mình đang bị treo (crash) liên tục. Khi bạn kiểm tra container theo cách thủ công, bạn gặp phải một trở ngại:
touch: cannot touch 'data.log': Read-only file system
Lỗi này là một trường hợp kinh điển. Ngay cả với tư cách là người dùng root, bạn cũng bị khóa khỏi hệ thống tệp của chính mình. Nó thường xảy ra khi Docker hoặc hệ điều hành máy chủ (host OS) quyết định rằng việc ghi vào đĩa là quá rủi ro, thường là do sai sót trong cấu hình hoặc cảnh báo về phần cứng.
Các cách khắc phục nhanh- Kiểm tra các mount flags: Hãy kiểm tra kỹ tệp docker-compose.yml của bạn. Một ký tự :ro vô tình ở cuối chuỗi volume sẽ khóa thư mục đó.- Quét tình trạng sức khỏe ổ đĩa máy chủ: Nhân Linux thường mount lại hệ thống tệp dưới dạng chỉ đọc (read-only) nếu chúng phát hiện lỗi I/O. Hãy chạy lệnh dmesg | grep -i "remount-ro" để xem liệu máy chủ có đang tự bảo vệ mình khỏi một ổ đĩa bị lỗi hay không.- Khởi động lại Docker Engine: Trên Mac hoặc Windows, máy ảo chạy Docker đôi khi có thể bị treo. Việc khởi động lại Docker Desktop nhanh chóng thường sẽ xóa các tệp bị khóa (file locks) cũ.## Các nguyên nhân và giải pháp phổ biến### 1. Các Mount chỉ đọc (Read-Only) rõ ràngSai sót trong cấu hình là nguyên nhân thường gặp nhất. Docker cho phép bạn mount các volume ở chế độ chỉ đọc để bảo vệ dữ liệu nhạy cảm của máy chủ khỏi các tiến trình trong container. Hãy tìm hậu tố :ro trong sơ đồ volume của bạn.
Ví dụ Docker Compose:
services:
app:
image: my-app:v2.1.0
volumes:
- ./configs:/app/config:ro # Ký tự 'ro' này ngăn chặn mọi hoạt động ghi
Cách khắc phục: Chuyển flag sang :rw hoặc xóa hoàn toàn. Docker mặc định là quyền đọc-ghi (read-write) nếu không có flag nào được chỉ định.
- ./configs:/app/config:rw
2. Hệ thống tệp máy chủ bị hỏngKhi nhân Linux gặp lỗi I/O nghiêm trọng trên phân vùng ext4 hoặc xfs, nó sẽ kích hoạt việc mount lại khẩn cấp. Động thái an toàn này ngăn chặn việc hỏng dữ liệu nhưng biến các volume của bạn thành vùng chỉ đọc. Điều này thường xảy ra khi bộ lưu trữ khối (block storage) của nhà cung cấp đám mây gặp sự cố nhỏ.
Kiểm tra log máy chủ của bạn ngay lập tức:
journalctl -k | grep -E "error|read-only"
Nếu bạn thấy 'EXT4-fs error', bạn có thể cần unmount ổ đĩa và chạy fsck. Nếu đây là máy chủ production, hãy kiểm tra bảng điều khiển đám mây để xem các thông báo về việc ngừng hoạt động phần cứng hoặc các vấn đề kết nối đĩa.
3. Giới hạn tài nguyên của Docker Desktop (Mac/Windows)Docker Desktop hoạt động bên trong một máy ảo ẩn. Máy ảo này sử dụng một tệp ảnh đĩa ảo (thường là Docker.raw) với kích thước cố định—thường là 64GB theo mặc định. Nếu đĩa ảo này đạt 100% dung lượng, hệ thống tệp nội bộ có thể chuyển sang chế độ chỉ đọc để ngăn chặn việc hỏng cơ sở dữ liệu.
Cách khắc phục:
- Kiểm tra thanh đo 'Disk usage' trong cài đặt Docker Desktop.- Dọn dẹp dữ liệu không sử dụng bằng lệnh
docker system prune -a --volumesđể thu hồi không gian.- Nếu ảnh đĩa bị hỏng, hãy sử dụng tùy chọn 'Reset to factory defaults'. Lưu ý rằng điều này sẽ xóa sạch các image và volume cục bộ của bạn.### 4. Thực thi SELinuxTrên các hệ thống được tăng cường bảo mật như RHEL, Fedora hoặc CentOS, SELinux quản lý các tiến trình nào có thể ghi vào các thư mục cụ thể. Ngay cả khi quyền Linux của bạn được đặt thành777, SELinux vẫn có thể chặn container. Điều này đôi khi biểu hiện dưới dạng lỗi chỉ đọc tùy thuộc vào storage driver. Hãy thử thêm flag:zhoặc:Zvào mount của bạn. Flag:zviết thường thông báo cho Docker rằng volume được chia sẻ giữa nhiều container, trong khi:Zviết hoa chỉ định một volume riêng tư, không chia sẻ.
docker run -v /data/storage:/app/data:Z my-image:latest
Read-Only so với Permission DeniedViệc phân biệt giữa hai lỗi này là rất quan trọng. Chúng yêu cầu các cách khắc phục rất khác nhau.
- Read-only file system: Toàn bộ 'đường ống' bị đóng. Không người dùng nào, kể cả root, có thể ghi dữ liệu. Đây là vấn đề ở cấp độ mount hoặc cấp độ phần cứng.- Permission denied: 'Đường ống' đang mở, nhưng ID người dùng (UID) cụ thể của bạn không có chìa khóa. Đây là vấn đề về
chmodhoặcchown.Nếu bạn khắc phục được lỗi chỉ đọc nhưng vẫn không thể ghi, người dùng trong container có khả năng thiếu các quyền chính xác. Tôi thường sử dụng Unix Permissions Calculator để xác minh rằng các chế độ số (như755) phù hợp với nhu cầu của ứng dụng. Nó giúp ngăn chặn thói quen 'chỉ cần chmod 777 mọi thứ', vốn là một rủi ro bảo mật đáng kể.
Các bước xác minhSau khi áp dụng bản sửa lỗi, đừng chỉ tin vào lời của ứng dụng. Hãy xác minh trạng thái mount trực tiếp:
- Kiểm tra các mount flags:
docker exec <container_id> mount | grep /your/pathTìm kiếm(rw,...). Nếu bạn vẫn thấy(ro,...), container vẫn chưa nhận được thay đổi cấu hình.- Thực hiện kiểm tra ghi thủ công:``` docker exec <container_id> dd if=/dev/zero of=/your/path/testfile bs=1M count=1

