Synology’s DSM is polished enough to be useful immediately, but deep enough to keep tuning indefinitely. This covers SMB shares, Docker containers via Container Manager, and the firewall configuration that keeps it accessible from the LAN while genuinely unreachable from the internet.
Initial setup
QuickConnect is skipped entirely — it routes traffic through Synology’s own relay servers to make remote access easier for less technical setups, which isn’t needed here given the network already has proper VLAN segmentation and (for anything that genuinely needs external access) Tailscale rather than relying on a third-party relay service sitting between me and my own data.
A static IP reservation and a renamed admin account are configured first, with the default admin account explicitly disabled — a disabled default admin account means the single most commonly brute-forced username on Synology devices simply doesn’t exist as a valid target.
Shares and SMB
Enable SMB service: Yes
Maximum SMB protocol: SMB3
Minimum SMB protocol: SMB2 (SMB1 disabled — long-deprecated, no integrity checking, no encryption support)
Enable SMB encryption: Yes
Disabling SMB1 specifically matters beyond general hygiene — it’s the protocol version EternalBlue and the WannaCry/NotPetya family of exploits targeted, and Synology (like most vendors) still ships it enabled by default on older DSM versions for backward compatibility with genuinely ancient clients that have no reason to be on this network.
Docker via Container Manager
Containers running on the Synology, each on its own defined Docker network rather than sharing the host network directly:
Uptime Kuma — service monitoring, covered in its own dedicated writeup, watching everything from the blog’s public uptime to internal service health
Watchtower — automatically keeps containers updated on a schedule:
services:
watchtower:
image: containrrr/watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
command: --schedule "0 0 4 * * *" --cleanup
Scheduled for 4am specifically to avoid any container restart happening during active use, and --cleanup removes old images after a successful update rather than letting them accumulate and quietly consume storage over months.
Firewall lockdown
Rule 1: Allow source LAN subnet all ports
Rule 2: Allow source DMZ subnet ports 80,443 (only if a specific service genuinely needs it)
Rule 3: Deny source All all ports
Rule 3 is the meaningful one — an explicit deny-all catch-all rather than relying on Synology’s default behaviour, since a NAS holding family photos and documents is a categorically worse thing to have exposed than a disposable web server. There is currently nothing on the Synology that needs DMZ access at all, so Rule 2 exists as a documented, deliberate placeholder rather than something actively in use — worth reviewing periodically to confirm it’s still true rather than becoming stale permissiveness nobody remembers granting.
Combined with Auto Block (Control Panel → Security → Auto Block) set to block an IP after 5 failed login attempts within 5 minutes, and 2FA enforced on all admin-level accounts via Control Panel → User & Group → Advanced → 2-step verification. Between the firewall rules and 2FA, even a leaked password alone isn’t sufficient for account takeover.
3-2-1 backup
Covered in full in its own dedicated writeup — the Synology sits as the local backup tier in a genuine 3-2-1 strategy, with primary storage on TrueNAS and an offsite copy synced to a dedicated SharePoint document library via Cloud Sync, rather than the Synology being treated as a backup destination in isolation.
Result
A NAS that’s genuinely useful for file shares and self-hosted containers, fully locked down from any inbound internet exposure via an explicit deny-all firewall rule rather than relying on default behaviour, with 2FA and auto-blocking protecting the admin interface, and SMB1 disabled entirely to remove a whole historical exploit class as a concern.