← All projects
storage · 28 Feb 2025 · 4 min read

Synology setup: shares, Docker, and keeping it off the open internet

How I set up my Synology NAS for file shares, running Docker containers, and locking it down so it's accessible from my network without being exposed to the internet.

Synology’s DSM (DiskStation Manager) is the most polished NAS operating system available. It’s approachable enough to be useful out of the box, but deep enough to keep tuning indefinitely. This writeup covers my full setup — SMB shares, Docker containers via Container Manager, firewall configuration, and a 3-2-1 backup strategy.

Initial DSM setup

Skip QuickConnect

The first thing DSM prompts you to do is enable QuickConnect — Synology’s relay service for remote access. Skip it. It routes your traffic through Synology’s servers, introduces an unnecessary third party, and isn’t needed if you have a proper network setup. Remote access via Tailscale is a better option.

Static IP

Before anything else, set a static IP so your firewall rules and share mappings don’t break when DHCP renews:

Control Panel → Network → Network Interface → LAN → Edit:

Use manual configuration: ✅
IP:      192.168.1.20
Mask:    255.255.255.0
Gateway: 192.168.1.1
DNS:     192.168.1.10 (DC if running AD), 1.1.1.1

Rename the admin account

The default admin account is a known target. Create a new admin user with a different name, then disable the default admin account:

Control Panel → User & Group → Create a new user, add to the administrators group. Log in as the new user, then disable admin under Control Panel → User & Group → admin → Edit → Disable.

Volume and share setup

Create a volume

Navigate to Storage Manager → Volume → Create. Select your drives and choose a RAID type:

2 drives:  SHR or RAID 1 (mirroring — protects against single drive failure)
3+ drives: SHR or RAID 5

Allocate the full capacity to one volume unless you have a specific reason to split it.

Create shared folders

Navigate to Control Panel → Shared Folder → Create:

media      — Plex/Jellyfin library (read: all authenticated, write: admin only)
backups    — Time Machine + Windows backups (per-user write access)
documents  — General file storage (per-user access control)
docker     — Container config and data (admin only)

Enable data checksum on all shares — this uses ZFS-style checksumming to detect and repair silent data corruption.

SMB configuration

Navigate to Control Panel → File Services → SMB:

Enable SMB service: ✅
Maximum SMB protocol: SMB3
Minimum SMB protocol: SMB2 (disable SMB1 — it's a security risk)
Enable Opportunistic Locking: ✅
Enable SMB encryption: ✅ (requires SMB3 clients)

For Windows clients, map drives via:

\\192.168.1.20\media
\\192.168.1.20\documents

For persistent mapping on Windows:

New-PSDrive -Name "M" -PSProvider FileSystem -Root "\\192.168.1.20\media" -Persist -Credential (Get-Credential)

Time Machine for macOS

Control Panel → File Services → AFP → Enable AFP service → Enable Bonjour Time Machine broadcast:

Share folder: backups
Time Machine quota per user: 500GB

Macs on the same network will discover the Time Machine destination automatically in System Preferences → Time Machine.

Docker via Container Manager

Synology’s Container Manager package is Docker with a GUI wrapper. Install it from Package Centre → Container Manager.

Containers I run on the Synology:

Jellyfin (media server)

Image:   jellyfin/jellyfin:latest
Volumes:
  /volume1/media    → /media     (read-only)
  /volume1/docker/jellyfin/config → /config
Ports:   8096:8096
Network: bridge

Uptime Kuma (service monitoring)

Image:   louislam/uptime-kuma:latest
Volumes:
  /volume1/docker/uptime-kuma → /app/data
Ports:   3001:3001
Network: bridge

Watchtower (auto-update containers)

Image:   containrrr/watchtower:latest
Volumes:
  /var/run/docker.sock → /var/run/docker.sock
Environment:
  WATCHTOWER_SCHEDULE: 0 0 3 * * *  (run at 3am daily)
  WATCHTOWER_CLEANUP: true

Firewall lockdown

This is critical. Synology devices are actively targeted by ransomware campaigns. Navigate to Control Panel → Security → Firewall → Edit Rules:

Rule 1: Allow  source 192.168.1.0/24  all ports
Rule 2: Allow  source 172.20.30.0/24  ports 80,443 (if DMZ needs access)
Rule 3: Deny   source All             all ports

The deny-all at the bottom means nothing from the internet can reach DSM. Rules are processed top to bottom.

Additional hardening:

Under Control Panel → Security → Protection:

Enable auto block: ✅
Block after:       5 failed login attempts
Block duration:    24 hours

Under Control Panel → Security → Account:

Enable 2-factor authentication: ✅ (enforce for all admin accounts)

Under Control Panel → Update & Restore:

Automatically install important updates: ✅

3-2-1 backup strategy

A NAS is not a backup. RAID is redundancy (protects against hardware failure), not backup (protects against accidental deletion, ransomware, or catastrophic failure). I run a 3-2-1 strategy:

3 copies of data:

  • Primary: the Synology volume itself
  • Secondary: Hyper Backup to a second internal share on a separate volume
  • Tertiary: offsite via Hyper Backup to Backblaze B2

2 different media types:

  • Spinning HDD in the Synology
  • Cloud storage (B2)

1 offsite copy:

  • Backblaze B2 (cold storage, very cheap — roughly £5/TB/month)

Setting up Hyper Backup to Backblaze B2

  1. Create a Backblaze account, create a B2 bucket, generate an application key
  2. Install Hyper Backup from Package Centre
  3. Create a new backup task: 
    Destination: S3-compatible storage
Server:      s3.us-west-004.backblazeb2.com (your region)
Bucket:      your-bucket-name
Access key:  your-keyID
Secret key:  your-applicationKey
  4. Select folders to back up
  5. Set schedule: daily at 2am
  6. Enable client-side encryption with a strong passphrase — Backblaze never sees your plaintext data

Verify your backups

Hyper Backup has a built-in restore test feature. Run it monthly. An untested backup is not a backup.

Layer 8