Synology không xóa được file: nguyên nhân và cách gỡ lock

File không chịu xóa không phải vì ổ cứng dở — là có ai đó đang níu lấy nó

Bấm Delete, DSM báo " access denied". Đổi tên file, màn hình đứng im mấy giây rồi báo "file đang được sử dụng bởi người khác". Phản xạ đầu tiên của nhiều người là nghi ổ cứng hỏng hoặc volume lỗi — oan cho ổ cứng. Phần lớn trường hợp này là do một kết nối hoặc tiến trình khác đang giữ "handle" trên file đó, và DSM đang làm đúng việc của nó: khóa file lại để không ai ghi đè lên dữ liệu người khác đang dùng.

Cái khó là lock có bốn "mặt" khác nhau hẳn, mò sai hướng là tốn cả buổi chiều mà không ra gì:

• SMB lock — máy Windows/macOS mở file qua ổ mạng, mất kết nối đột ngột (ngủ máy, rút mạng) để lại "ghost lock".
• NFS stale handle / permission denied — máy Linux, Docker, VM mount NFS, container restart hoặc export đổi khiến handle cũ không còn hợp lệ.
• Phân quyền shared folder / ACL — hai lớp quyền Unix permission và Windows ACL đá nhau, dù nhìn qua tưởng đã cấp đủ quyền.
• Recycle Bin / @eaDir — thư mục rác và metadata ẩn của DSM khiến folder "nhìn trống" mà dọn không hết.

Bài phân quyền shared folder Synology dạy cách cấp quyền từ đầu. Bài này khác: quyền đã đúng rồi, nhưng file vẫn bị khóa bởi thứ gì đó còn sót lại trong kết nối.

Chẩn đoán nhanh: lỗi đang thuộc nhóm nào

Trước khi làm gì, nhìn xem lỗi xảy ra ở đâu và báo thông báo gì. Bảng dưới giúp bạn nhảy thẳng vào mục cần đọc, đỡ dò từ đầu.

Nhóm 1 — SMB: Windows/macOS giữ "ghost lock" trên ổ mạng

Case kinh điển: nhân viên mở file Excel qua ổ mạng map từ Synology, máy ngủ hoặc mất điện giữa chừng. Windows vẫn nghĩ nó đang giữ file, Synology vẫn thấy một session SMB chưa đóng đúng cách. Không ai xóa, đổi tên, hay di chuyển được file đó — dù người "đang mở" nó đã tắt máy từ lâu.

Xử lý theo đúng thứ tự ít rủi ro nhất:

1. Đóng file ở mọi máy đang có khả năng mở nó (không chỉ máy đang báo lỗi — Word/Excel autosave rất hay mở ngầm ở máy khác).
2. Disconnect rồi reconnect ổ mạng. Trên Windows, cách chắc tay nhất là gõ net use \\NAS_IP\share /delete trong Command Prompt để xóa sạch kết nối cache, rồi map lại ổ từ đầu. Bước này không cần quyền admin, không ảnh hưởng ai khác, và giải quyết hơn một nửa case thuộc dạng cache Windows.
3. Nếu vẫn kẹt, vào Control Panel > Shared Folder, chọn folder, Edit > Permissions / Advanced Permissions kiểm lại quyền cho chắc — đôi khi đây lại là lúc phát hiện ra vấn đề thật sự nằm ở nhóm 3, không phải lock.
4. Vẫn không được: vào Control Panel > File Services > SMB, tắt dịch vụ SMB rồi mở lại. Việc này buộc Synology giải phóng toàn bộ handle SMB đang treo — hiệu quả tương đương lệnh synoservicectl --restart smbd qua SSH, nhưng làm qua giao diện thì không cần biết tên service, không cần quyền root.

Bước 4 có một cái giá phải trả: tắt/mở SMB service làm rớt kết nối của tất cả người đang dùng SMB trên NAS, không riêng gì file bạn đang xử lý. Làm giữa giờ làm việc là cách nhanh nhất để cả phòng gõ cửa hỏi "sao Excel của tôi tự đóng". Báo trước hoặc làm ngoài giờ.

Nhóm 2 — NFS: Linux, Docker, VM mount báo denied hoặc stale handle

Case này rơi vào server Linux hoặc container Docker mount NFS từ Synology. Hai thông báo khác nhau, hai cách xử lý khác nhau — đừng gộp chung:

"Permission denied" dù trước đó chạy bình thường: thường do một rule "No access" ẩn cho client IP hoặc user map tới trong phần NFS Permissions của shared folder , không phải do quyền file bên trong. Vào Control Panel > Shared Folder, chọn folder, tab NFS Permissions, kiểm lại rule theo IP/subnet của máy client — bỏ tick "No access" nếu nó đang chặn ngầm user hoặc squash root đang dùng.

"Stale file handle" hoặc "Device busy" sau khi container restart: export NFS đã đổi (folder bị xóa/tạo lại, hoặc NAS restart) nhưng client vẫn giữ handle cũ trỏ vào inode không còn tồn tại. Đây là việc của phía client, NAS không sửa được từ xa. Umount đúng cách:

umount -f /mount_point   # force unmount, dùng khi handle đã stale
umount -l /mount_point   # lazy unmount, dùng khi -f vẫn báo busy

Cạm bẫy hay gặp nhất ở đây: gõ umount trơn không kèm -f hay -l. Lệnh treo mãi không thoát vì kernel vẫn đang chờ handle cũ phản hồi — mà nó sẽ không bao giờ phản hồi. Mount lại bằng đúng lệnh mount ban đầu sau khi umount thành công.

Nhóm 3 — Phân quyền shared folder / ACL đá nhau

DSM có hai lớp quyền chạy song song: Unix permission (rwx kiểu Linux truyền thống) và Windows ACL (chi tiết hơn, theo kiểu NTFS). Hai lớp này không phải lúc nào cũng đồng bộ. Admin đứng check thấy ACL ghi "Full Control" nhưng Unix permission bên dưới lại giới hạn hơn (hoặc ngược lại) — DSM áp theo lớp chặt hơn, và kết quả là xóa cứ báo lỗi từng file một dù "nhìn thấy" quyền đủ trên màn hình.

Đây chính là lúc dễ nhầm với lock nhất: sửa quyền xong tưởng xong, thử lại vẫn lỗi y nguyên — vì bản chất không phải thiếu quyền, mà file đang bị một client khác giữ (quay lại nhóm 1 hoặc 2). Luật chẩn đoán đơn giản: nếu đã kiểm ACL/Unix permission kỹ theo bài phân quyền shared folder và thấy ổn, nhưng lỗi vẫn lặp lại đúng kiểu cũ, 90% là lock chứ không phải quyền. Đừng vòng lại sửa quyền thêm lần nữa, tốn thời gian.

Nhóm 4 — Recycle Bin (#recycle) và @eaDir dọn không hết

Case thường gặp: bấm "Empty Recycle Bin" trên File Station, tưởng sạch, nhưng vẫn còn sót folder rác. Lý do: mỗi shared folder có một thư mục ẩn tên #recycle chứa file đã xóa, và DSM còn tự sinh thêm thư mục metadata/thumbnail ẩn tên @eaDir bên trong hầu hết các folder có ảnh/video — folder này tự tái tạo mỗi khi có truy cập, nên xóa xong lại thấy nó mọc lại là bình thường, không phải lỗi.

Xử lý: trong File Station, vào menu View (góc trên) bật "Show hidden files" để thấy #recycle và @eaDir, chọn xóa trực tiếp qua giao diện. Chỉ khi File Station vẫn báo lỗi hoặc không xóa được mới cần vào SSH xóa thủ công — và nhớ chụp snapshot hoặc backup trước, vì xóa nhầm @eaDir gốc (không phải bản cache) có thể mất metadata thumbnail của cả thư viện ảnh.

Lỗi thường gặp khi tự xử lý (và cách tránh)

• Xóa thẳng tay theo lô qua File Station khi folder đang bị khóa — DSM báo lỗi liên tục từng file, càng bấm càng rối. Dừng lại, xác định ai đang mở trước, xử lý lock xong mới xóa lại theo lô.
• Kill process theo PID lấy từ fuser mà không xem trước đó là ai — rất có thể là tiến trình của đồng nghiệp đang lưu file giữa chừng, kill là mất dữ liệu người ta chưa lưu kịp.
• Tắt/mở SMB service giữa giờ làm việc — rớt kết nối toàn bộ người dùng khác trên NAS, không riêng người đang gặp lỗi. Làm ngoài giờ hoặc báo trước trong group chat công ty.
• Nhầm lỗi lock với lỗi phân quyền — sửa quyền hoài không dứt vì bản chất file đang bị client khác giữ. Nhận ra sớm đỡ mất cả buổi chỉnh ACL vô ích.
• umount trơn khi gặp stale handle — lệnh treo không thoát, phải Ctrl+C rồi dùng -f/-l như hướng dẫn ở nhóm 2.

Tùy chọn nâng cao: SSH khi GUI đã chịu thua (không bắt buộc)

Đây là bước cuối cùng, chỉ dùng khi ba bước GUI ở trên không ăn. Cần vào Control Panel > Terminal & SNMP để bật SSH trước — và tắt lại ngay sau khi xử lý xong, SSH với quyền root trên Synology là bề mặt rủi ro không nên để mở lâu.

# Xem tiến trình nào đang mở file trong thư mục
fuser -m /volume1/ten_folder

# Liệt kê chi tiết file đang mở trong thư mục (cần quyền tương ứng)
lsof +D /volume1/ten_folder

# Xem lock ở cấp Samba (cần root)
smbstatus -L

# Khởi động lại SMB service qua dòng lệnh (tương đương tắt/mở ở Control Panel)
synoservicectl --restart smbd

Chỉ khi xác định chắc PID đó không phải của ai khác đang làm việc, mới dùng fuser -k <file> hoặc kill -9 <PID> để buộc đóng. kill -9 cắt ngang tiến trình đang ghi file có thể làm hỏng file nửa chừng — nặng nhất là database hoặc file ảnh VM đang chạy. Ưu tiên đóng ứng dụng đúng cách ở phía client trước, coi lệnh này là phương án chót thật sự chót.

Muốn giảm tần suất gặp lock do laptop ngủ/roaming mạng, có thể vào Control Panel > File Services > SMB > Advanced Settings tinh chỉnh Opportunistic Locking (Oplocks), SMB2 Lease, Durable Handle. Nhưng đây là cấu hình ảnh hưởng toàn bộ share, chỉ nên đụng khi đã hiểu rõ cơ chế — tắt Oplocks "cho dễ" đổi lại là giảm cache hiệu năng cho mọi client, không phải cái giá nên trả chỉ vì một file kẹt lock mỗi tháng một lần.

Phòng tránh để đỡ gặp lại

Với case SMB: khuyến khích người dùng đóng file trước khi đóng máy hoặc để máy ngủ, thay vì để Windows tự "đoán" là đã lưu xong. Với NFS: luôn umount đúng thứ tự trước khi NAS restart hoặc export đổi, đừng để client tự xử bằng umount trơn. Với phân quyền: một khi đã set ACL/Unix permission đúng theo bài phân quyền shared folder, không cần sửa lại mỗi lần gặp lỗi lock — nhận diện đúng nhóm nguyên nhân quan trọng hơn việc chỉnh quyền thêm lần nữa.

Tin tốt là hướng dẫn DSM ở trên dùng được cho cả 7.2.2, 7.3.2 lẫn bản 7.4.1-90080 hiện tại — Synology không đổi tên các menu Control Panel liên quan qua các bản 7.x, nên khỏi lo "làm theo bài cũ có còn đúng không". Cái duy nhất thay đổi là file của bạn có chịu nhả ra hay không — và giờ thì bạn đã biết hỏi đúng chỗ.