Ổ cứng ngoài purple trên Raspberry Pi — mount tự động và spin-down

Tóm tắt

Ghi chép quá trình gắn cố định ổ cứng ngoài Buffalo 1TB (label purple, exFAT) vào /mnt/purple trên Raspberry Pi 4 (10.0.0.22, Ubuntu 26.04 LTS arm64) ngày 2026-08-03: tạo mount point, thêm dòng /etc/fstab theo UUID với nofail, và cho ổ tự ngừng quay sau 10 phút rảnh. Điểm mấu chốt là hdparm -S không dùng được với cầu USB-SATA của Buffalo (không hỗ trợ ATA passthrough) mà vẫn in ra output trông như thành công — phải thay bằng hd-idle gửi lệnh SCSI START STOP UNIT. Trong lúc làm còn phát hiện một dòng /etc/fstab hỏng từ trước (swap bị dán nhầm chữ) và đã sửa.

Điểm chính

• Ổ nhận diện là /dev/sda, phân vùng dữ liệu sda2 (931.3G, exFAT, label purple, UUID 67F4-98D0) mang nguyên bảng phân vùng kiểu macOS, đã dùng ~647G (§1).
• Việc này từng làm dở: ổ đã format và đặt label nhưng chưa có mount point lẫn dòng fstab nào, nên mỗi lần boot ổ không tự lên (§1).
• Dòng fstab dùng UUID= thay vì /dev/sda2 vì tên sd* phụ thuộc thứ tự enumerate USB, cắm thêm ổ khác là mount sai ổ (§3).
• nofail là bắt buộc với ổ USB cắm rời — thiếu nó, rút ổ ra là Pi treo ở emergency shell khi boot; kèm x-systemd.device-timeout=15s để không chờ mãi (§3).
• exFAT không có quyền POSIX nên quyền hoàn toàn do mount option quyết định: uid=1000,gid=1000,umask=002 để user thường ghi được mà không cần sudo; noatime tránh việc đọc sinh write đánh thức ổ vừa ngủ (§3).
• exFAT ở đây dùng driver trong kernel (module exfat), không phải FUSE; gói exfatprogs chỉ cần cho mkfs/fsck, không cần để mount (§3).
• hdparm -S thất bại vì cầu USB-SATA Buffalo/VIA không hỗ trợ ATA passthrough — lỗi thật nằm ở dòng SG_IO: bad/missing sense data, nhưng ngay sau đó hdparm vẫn in setting standby to 120 (10 minutes) và drive state is: standby trông như thành công (§4).
• hdparm -I /dev/sda trả về thông tin rỗng (0 cylinders, device size 0 MBytes) — thêm một dấu hiệu passthrough không đi tới đĩa (§4).
• hd-idle gửi lệnh SCSI START STOP UNIT qua tầng SCSI/USB — đúng đường ổ USB hiểu — và tự theo dõi bộ đếm I/O để biết ổ có thực sự rảnh (§4).
• Thứ tự tham số của hd-idle có nghĩa: -i 0 đặt trước -a để mặc định tắt idle cho mọi đĩa khác (nếu không sẽ áp cả cho thẻ microSD chạy hệ điều hành), -i 600 đặt sau -a để chỉ áp cho ổ vừa nêu (§4).
• Trỏ thiết bị qua /dev/disk/by-id/usb-BUFFALO_... kèm -s 1 để resolve symlink lúc runtime, cùng lý do với việc dùng UUID trong fstab (§4).
• Bất kỳ tiến trình nào quét /mnt/purple định kỳ (media server scan, cron backup, indexer) sẽ reset đồng hồ idle và ổ không bao giờ ngủ — phải chỉnh lịch quét bên đó, không phải chỉnh hd-idle (§5).
• /etc/fstab có sẵn một dòng hỏng: /var/swap swap swap defaults 0 0 vào sudo vim /etc/fstab — parser bỏ qua field thừa nên swap vẫn chạy và lỗi im lặng rất lâu, chỉ lộ ra qua systemd-analyze verify /etc/fstab (§6).
• Bài học vận hành: sau mỗi lần sửa fstab, chạy findmnt --verify --verbose trước khi reboot (§6).

Cập nhật 2026-08-03 — chia sẻ ổ ra mạng bằng Samba (SMB)

Phần này ghi trực tiếp từ việc làm trên máy trong ngày, không có trong tệp raw gốc.

Sau khi ổ đã mount ổn định, mục tiêu tiếp theo là xem kho phim 647G từ iPhone/iPad (Infuse) và MacBook. Ban đầu định dùng MiniDLNA như cai-dat-minidlna-tren-raspberry-pi đã ghi, nhưng cuối cùng chọn Samba (SMB).

Vì sao SMB chứ không phải MiniDLNA hay Jellyfin

Tiêu chí	Samba (đã chọn)	MiniDLNA	Jellyfin
Quét thư viện	không quét → ổ ngủ được	có quét/inotify → đánh thức ổ	quét metadata liên tục → đánh thức ổ
RAM	~30–50 MB	~50 MB	~400 MB (máy chỉ còn ~438 MB rảnh)
Phụ đề .srt rời	client tự đọc, chạy tốt	hên xui tuỳ client DLNA	tốt
Giao diện thư viện	không có, duyệt theo tên file	sơ sài	đẹp (poster, nhớ vị trí xem)

Yếu tố quyết định là không quét thư viện: cảnh báo ở §5 của ghi chép gốc nói bất kỳ tiến trình nào quét /mnt/purple định kỳ sẽ khiến hd-idle không bao giờ cho ổ ngủ. Samba chỉ đọc khi người dùng thực sự mở file, nên giữ được spin-down vừa cấu hình. Ràng buộc RAM cũng loại Jellyfin: Pi chỉ có 1.8 GiB, đã dùng ~1.4 GiB cho AdGuard, WordPress stack và cloudflared.

Cấu hình đã áp dụng

Cài samba + avahi-daemon, cấu hình tại /etc/samba/smb.conf (bản gốc đã sao lưu thành smb.conf.bak.<timestamp>):

• Share [purple] → /mnt/purple, đọc-ghi, valid users = _, force user/group = _ (khớp uid=1000 mà exFAT được mount).
• interfaces = lo eth0 + bind interfaces only = yes — không bind vào 3 bridge Docker đang có trên máy.
• hosts allow = 10.0.0.0/24, hosts deny = 0.0.0.0/0, map to guest = never, restrict anonymous = 2, server min protocol = SMB3, smb encrypt = desired.
• disable netbios = yes + chỉ cổng 445 (macOS/iOS không cần NetBIOS); nmbd đã disable và mask.
• log level = 0 — hệ điều hành chạy trên microSD, giảm số lần ghi.
• hide files ẩn .DS_Store, ._*, .Spotlight-V100, $RECYCLE.BIN cho gọn.
• Không bật vfs_fruit (bộ tối ưu cho macOS): nó cần extended attribute mà exFAT không có.
• avahi-daemon quảng bá _smb._tcp để Finder tự thấy máy tên pi trong mục Network.

Mật khẩu SMB đặt riêng bằng smbpasswd -a _, không dùng chung mật khẩu đăng nhập máy.

Kết quả kiểm tra

Cổng 445 thông từ MacBook, mDNS quảng bá đúng, tài khoản SMB trạng thái enabled, và người dùng xác nhận mở phim từ client chạy được. RAM sau khi cài còn ~501 MB rảnh (nhỉnh hơn trước khi cài, do buff/cache dịch chuyển).

Lưu ý còn lại

Kho phim là BluRay remux 1080p và 4K HEVC/Dolby Vision, bitrate rất cao. Pi không transcode — thiết bị phát phải tự giải mã được. Nếu giật thì nút thắt nằm ở client, không phải ở Pi hay mạng.

Khái niệm

• fstab-mount-tu-dong
• exfat-tren-linux
• spin-down-o-cung-usb
• samba-smb-file-sharing

Nguồn liên quan

• cai-dat-minidlna-tren-raspberry-pi — phương án đã cân nhắc nhưng không chọn: inotify=yes sẽ đánh thức ổ liên tục, xem phần “Cập nhật 2026-08-03” ở trên.
• topology-mang-homelab — bối cảnh máy: các dịch vụ đang chạy trên Pi.

Người liên quan

• nguyen-binh-son

Câu hỏi mở

• Sau reboot thật, ổ có tự mount và hd-idle có tự chạy đúng không? (Ngày ghi chép mới chỉ test mount -a và ép ngủ thủ công, chưa reboot xác nhận.)
• Khi bật lại MiniDLNA, chọn cách nào: bỏ inotify, đặt lịch quét thưa, hay để media ở nơi khác /mnt/purple? Đã khép lại (2026-08-03): không dùng MiniDLNA nữa, chuyển sang Samba vì nó không quét thư viện — xem phần “Cập nhật 2026-08-03”.
• Ổ có thực sự ngủ được khi share SMB đang mount trên máy khác không? Một số client giữ handle mở hoặc quét thư mục nền (Finder xem trước thumbnail, Infuse tải metadata) có thể vẫn đánh thức ổ — chưa quan sát đủ lâu để kết luận.
• Ổ ngủ rồi thức lại nhiều lần có hại tuổi thọ hơn để quay liên tục không — 10 phút có phải ngưỡng hợp lý?