Cài n8n trên Synology bằng Docker, né lỗi permission

N8N là gì mà dân NAS đang rần rần cài?

n8n là công cụ tự động hóa workflow kiểu "kéo-thả node" — bạn ghép các khối chức năng lại thành một chuỗi, máy tự chạy thay bạn, không cần biết code. Nó giải quyết đúng cái nỗi đau muôn thuở của dân NAS: việc gì lặp đi lặp lại mà vẫn phải tự tay làm thì sớm muộn cũng bị quên, và thường quên đúng lúc quan trọng nhất.

n8n làm được khá nhiều việc đáng giá:

• Chạy theo lịch (cron) hoặc theo sự kiện qua webhook — ai đó gọi một URL là workflow chạy ngay lập tức.
• Nối chuỗi nhiều dịch vụ trong một luồng: nhận dữ liệu, xử lý, rồi bắn đi nhiều nơi cùng lúc (Telegram, Discord, Gmail, Google Drive...).
• Lưu 100% dữ liệu và credentials ngay trên NAS của bạn — không phải trả phí cloud, không lo dịch vụ bên thứ ba đọc dữ liệu nhạy cảm.
• Có node Execute Command, Read/Write File để thao tác trực tiếp lên hệ thống NAS, không chỉ gọi API ra ngoài.

Nghe hơi trừu tượng thì thử vài case thực tế coi sao. Bạn muốn Hyper Backup chạy xong rồi tự báo Telegram thành công hay thất bại — thay vì cứ vài hôm lại mở DSM lên xem có lỗi gì không. Hoặc UPS mất điện, ổ đĩa sắp đầy, DSM bắn cảnh báo — bạn muốn cảnh báo đó tỏa ra cả Email, Telegram, Discord cùng lúc chứ không chỉ nằm im trong DSM Notification chờ bạn tình cờ mở lên đọc. Hoặc file mới đổ vào một Shared Folder là tự động resize ảnh, đổi định dạng, đẩy lên Google Drive — không cần ngồi làm tay từng file.

So với cách "cổ điển" của dân NAS lâu năm là tự viết cron job + shell script, n8n cho giao diện trực quan hơn hẳn và có sẵn hàng trăm integration dựng sẵn — khỏi phải tự mò cách gọi API của Telegram hay Google Drive. So với Node-RED (một lựa chọn tương tự cũng chạy được trên NAS), n8n thiên về tích hợp dịch vụ SaaS nhiều hơn là điều khiển phần cứng IoT.

Vì sao chọn Docker qua Container Manager, không phải cách khác

Trước khi vào phần cài, cần nói rõ một điều: Synology không có package n8n chính thức trong Package Center. Nên câu hỏi không phải "native hay Docker" mà là chọn giữa ba cách không chính thức: cài tay qua SSH, chạy trong Virtual Machine, hoặc chạy Container qua Container Manager. Bài này đi theo Container Manager, và đây là lý do.

Cài tay qua Node.js + PM2 là cách nhiều bài hướng dẫn cũ hay chỉ, nhưng Synology không hỗ trợ chính thức kiểu này. DSM update một phát là service có thể chết theo, và bạn phải tự canh chừng, tự khởi động lại — vất vả không cần thiết cho một công cụ đáng lẽ nên "cài rồi quên".

Chạy trong Virtual Machine Manager thì ổn định, nhưng cấp cả một cỗ máy ảo cho một web app đơn lẻ là phí phạm — riêng RAM, riêng CPU, riêng ổ đĩa, backup/restore cũng cồng kềnh hơn hẳn so với backup một thư mục volume Docker.

Container qua Container Manager giải quyết gọn nhất: cập nhật chỉ cần pull image mới trong khi dữ liệu vẫn nguyên trong volume, container cô lập với hệ thống NAS nên ít khả năng phá DSM, và backup thì chỉ cần backup đúng một thư mục. Đánh đổi duy nhất: NAS của bạn phải thuộc dòng CPU hỗ trợ Docker. Mấy dòng giá rẻ dùng chip Realtek/Marvell như DS223j, DS118 thì chịu, không cài được.

Chuẩn bị trước khi cài

• DSM 7.x, đã cài package Container Manager (tên mới của package Docker từ DSM 7.2 trở đi).
• NAS thuộc dòng CPU x86/ARM64 có hỗ trợ Docker — kiểm tra trong Package Center xem Container Manager có hiện ra không, hiện được là chạy được.
• Truy cập được File Station và SSH (SSH chỉ cần cho một bước chown, không phải cài cả command line n8n).

Các bước cài n8n bằng Docker

1. Cài Container Manager

Vào Package Center, gõ "Container Manager", bấm cài như mọi package khác. Không có gì đặc biệt ở bước này.

2. Tạo thư mục volume cho n8n

Mở File Station, tạo đường dẫn docker/n8n/data trong /volume1 (tức /volume1/docker/n8n/data). Đây là nơi n8n sẽ lưu toàn bộ workflow, credentials và database SQLite — coi như "ổ cứng riêng" của n8n.

3. Chown thư mục về UID:GID 1000:1000 — bước hay bị bỏ quên nhất

Container n8n chạy bằng user có UID 1000 bên trong, trong khi thư mục bạn vừa tạo qua File Station mặc định thuộc quyền admin/root. Không khớp UID là container không ghi được vào volume. SSH vào NAS và chạy:

sudo chown -R 1000:1000 /volume1/docker/n8n/dataLàm bước này trước khi start container lần đầu. Bỏ qua bước này là gần như chắc chắn dính lỗi permission ngay lần chạy đầu tiên — phần lỗi thường gặp bên dưới sẽ nói kỹ hơn.

4. Tải image n8n

Trong Container Manager > Registry, tìm n8nio/n8n (image chính thức là docker.n8n.io/n8nio/n8n, nhưng image trên Docker Hub n8nio/n8n vẫn dùng được và dễ tìm hơn trong Registry của Container Manager). Chọn tag latest để lấy bản mới nhất, hoặc ghim một version cụ thể kiểu 1.6x.x nếu bạn muốn kiểm soát thời điểm update.

5. Tạo container

Tạo container mới từ image vừa tải, cấu hình:

• Port: map local 5678 → container 5678.
• Volume: /volume1/docker/n8n/data → /home/node/.n8n (rw). Đây là volume bắt buộc.
• Volume tùy chọn: nếu workflow cần đọc/ghi file trực tiếp lên NAS, map thêm /volume1/docker/n8n/files → /files.
• Restart policy: Always — để container tự bật lại khi NAS reboot.

6. Set biến môi trường

Thêm các biến sau vào cấu hình container:

GENERIC_TIMEZONE=Asia/Ho_Chi_Minh
TZ=Asia/Ho_Chi_Minh
N8N_ENCRYPTION_KEY=N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true

Hai biến timezone là bắt buộc nếu không muốn lịch cron chạy lệch giờ — mặc định n8n dùng UTC, tức lệch 7 tiếng so với giờ Việt Nam. N8N_ENCRYPTION_KEY quan trọng hơn bạn nghĩ: đây là key mã hóa toàn bộ credentials đã lưu trong n8n (API key Telegram, Google, mật khẩu SMTP...). Đặt một lần rồi backup lại key này ở nơi khác NAS luôn — mất key là mất khả năng đọc credentials, kể cả khi bạn vẫn còn nguyên file database.

Nếu định expose n8n ra internet (nói ở phần sau), thêm thêm:

N8N_HOST=n8n.your-ddns.synology.me
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.your-ddns.synology.me/
N8N_PROXY_HOPS=1

7. Khởi động và tạo tài khoảnStart container, đợi vài giây rồi vào trình duyệt gõ http://[IP-NAS]:5678. Lần đầu vào, n8n sẽ hỏi bạn tạo tài khoản admin — email, mật khẩu. Xong bước này là có giao diện n8n đầy đủ để bắt đầu kéo-thả workflow.

Muốn dùng webhook từ internet: Reverse Proxy, không phải Web Station

Nếu chỉ chạy workflow nội bộ (cron backup, xử lý file trong NAS) thì dừng ở bước trên là đủ, không cần mở ra internet làm gì cho rủi ro. Nhưng nếu bạn cần webhook — ví dụ Shopee, GitHub, hay một dịch vụ ngoài gọi vào n8n — thì phải expose ra ngoài, và đây là chỗ dễ vấp nhất.

Cấu hình DDNS trước (Control Panel > External Access > DDNS). Sau đó vào Control Panel > Login Portal > Advanced > Reverse Proxy — chú ý, đây là Reverse Proxy Server, khác hoàn toàn với việc dùng Web Station để publish site. Web Station không hỗ trợ WebSocket, mà giao diện n8n (đặc biệt là editor, nút test workflow) cần WebSocket để hoạt động mượt. Dùng nhầm Web Station là editor sẽ đơ, không báo lỗi rõ ràng, chỉ đứng im.

Tạo rule reverse proxy trỏ domain HTTPS về localhost:5678, sau đó vào tab Custom Header của rule đó, thêm hai header bắt buộc:

Thiếu hai header này là coi như dùng Web Station — WebSocket vẫn không chạy dù bạn đã đổi sang Reverse Proxy Server.

Test thử một workflow

Đừng vội chạy workflow production ngay. Tạo một workflow test nhỏ trước: node Cron Trigger (chạy mỗi phút) nối vào node HTTP Request gọi ra một API bất kỳ, hoặc node gửi Telegram. Chạy thử vài lần xem log có báo thành công không, giờ giấc có đúng múi giờ Việt Nam không.

Khi ổn rồi, thử tiếp một workflow webhook thật — ví dụ tạo node Webhook nhận request từ DSM Notification (DSM hỗ trợ gửi thông báo qua webhook tùy chỉnh trong Control Panel > Notification). Đây cũng chính là lúc bạn biết ngay WEBHOOK_URL và cấu hình WebSocket ở trên có chạy đúng hay không.

Vài ý tưởng workflow đáng làm theo khi đã quen tay:

• Backup trigger: Cron chạy hàng đêm → Execute Command kích hoạt task Hyper Backup → kiểm tra kết quả → gửi Telegram báo thành công hoặc lỗi.
• Notification chain: Webhook nhận cảnh báo từ DSM (ổ đầy, UPS mất điện...) → fan-out cùng lúc ra Email, Telegram, Discord.
• File sync tự động: Trigger khi có file mới trong Shared Folder → resize/convert ảnh → upload lên Google Drive hoặc S3.

Lỗi thường gặp

• EACCES: permission denied, open '/home/node/.n8n/config' — thư mục volume vẫn thuộc quyền root/admin trong khi container chạy bằng UID 1000. Fix: chown lại thư mục chown -R 1000:1000 /volume1/docker/n8n/data rồi restart container.
• Editor treo, bấm nút Stop không có phản hồi khi test webhook — do publish qua Web Station thay vì Reverse Proxy Server, WebSocket không được hỗ trợ. Fix: chuyển hẳn sang Reverse Proxy Server, thêm hai custom header Upgrade/Connection như hướng dẫn trên.
• Webhook không nhận request, URL hiển thị vẫn là localhost:5678 — thiếu WEBHOOK_URL hoặc N8N_PROXY_HOPS khi chạy sau proxy. Fix: set đủ WEBHOOK_URL dạng https://... kèm dấu / cuối, và N8N_PROXY_HOPS=1.
• Mất workflow/dữ liệu sau khi update container hoặc reboot NAS — do quên map volume, dữ liệu nằm trong container thay vì trên NAS, container bị xóa/tạo lại là mất sạch. Fix: luôn map /home/node/.n8n ra thư mục thật ngay từ lần chạy đầu, đừng để "chạy thử rồi map sau".
• Lịch cron chạy lệch giờ — thiếu GENERIC_TIMEZONE/TZ, n8n mặc định chạy theo UTC. Fix: set cả hai biến về Asia/Ho_Chi_Minh.

Bảo mật và bảo trì

Backup N8N_ENCRYPTION_KEY ở một nơi tách biệt khỏi NAS — ghi ra giấy, lưu password manager, gì cũng được, miễn không chỉ nằm trong đầu bạn. Mất key thì mọi credentials đã lưu trong n8n coi như vô dụng, dù database SQLite vẫn còn nguyên.

Đừng dùng UPnP để mở thẳng port 5678 ra internet. Route qua DDNS + Reverse Proxy + HTTPS như đã hướng dẫn, và bật xác thực hai lớp cho tài khoản n8n nếu có nhiều người dùng chung. Khi n8n xử lý dữ liệu nhạy cảm (API key của dịch vụ khác), đặt N8N_PROTOCOL=https và bật HSTS ngay trên reverse proxy.

Với các workflow dùng node Execute Command để thao tác trực tiếp lên NAS — chạy backup, xóa file cũ... — giới hạn quyền của user chạy lệnh, và test kỹ trên dữ liệu không quan trọng trước khi cho chạy production. Một dòng lệnh sai trong node Execute Command có thể xóa nhầm cả thư mục, và lúc đó thì không còn là chuyện của n8n nữa.

Cuối cùng, backup định kỳ thư mục volume data qua Hyper Backup — nơi chứa cả SQLite database, credentials và toàn bộ workflow — tách riêng khỏi lịch backup thường của NAS. Workflow tự động mà mất sạch chỉ vì quên backup thì đúng là tự động... quay lại vạch xuất phát.