DB-유

NFS Shares on Synology for Linux Clients

· synology, nfs, linux

I used SMB from my Linux servers for longer than I should have. It works, but ownership gets mapped away, permission bits are faked, and many small files crawl. NFS gives a Linux client a real POSIX view of the share with far less overhead. It matters when the NAS backs a web server, a media box, or Docker volumes on another host.

This covers enabling NFS on DSM 6.2, exporting a shared folder (I'll use data) with sensible squash and security settings, and mounting it on CentOS 7 and Ubuntu 18.04 via fstab and systemd automount. Know the client's IP or subnet, because Synology authorises NFS by host, not by user. And keep the UID problem in mind: NFS sends numeric UIDs, so if client UID 1000 writes a file, the NAS stores it as whichever NAS user has UID 1000, if any.

Enable the NFS service

Control Panel → File Services → NFS (in DSM 6.2 it is under the SMB/AFP/NFS tab):

Enable NFS:                      on
Enable NFSv4 support:            on
NFSv4 domain:                    example.com (leave blank to use the default)
Apply default UNIX permissions:  off (see Step 4)
Read/write packet size:          8 KB default; raise to 32 KB for 10 GbE

NFSv4 support enables a single port, TCP 2049, for the protocol, which simplifies firewalling. NFSv3 needs the portmapper on 111 plus mountd on a dynamic port, so if you must use v3, add the "NFS" built-in application to the DSM firewall rather than a single port.

NFS rule on the shared folder

Control Panel → Shared Folder → select data → Edit → NFS Permissions → Create:

Hostname or IP:            10.20.30.0/24
Privilege:                 Read/Write
Squash:                    No mapping
Security:                  sys
Enable asynchronous:       on
Allow connections from non-privileged ports: off
Allow users to access mounted subfolders: on

The squash setting decides what happens to root on the client:

  • No mapping: client root is root on the export. Use for trusted servers where you need to chown files.
  • Map root to admin: root becomes the NAS admin user. A reasonable default.
  • Map root to guest: root becomes guest, so nothing root does on the client can touch files not writable by guest.
  • Map all users to admin: everyone becomes admin; useful for a media box where ownership is irrelevant and the UID mismatch would otherwise be a nuisance.

The dialog shows the mount path at the bottom, /volume1/data. That is what the client needs.

Mounting on the client

Install the client utilities first:

# CentOS 7
sudo yum install -y nfs-utils
# Ubuntu 18.04
sudo apt install -y nfs-common

Test a manual mount over NFSv4:

sudo mkdir -p /mnt/nasdata
sudo mount -t nfs4 -o rw,hard,timeo=600,retrans=2 10.20.30.5:/volume1/data /mnt/nasdata
df -h /mnt/nasdata

Use hard rather than soft. A soft mount returns I/O errors to applications during a NAS reboot; a hard mount blocks until it returns, which is almost always what you want for data you care about. Add intr only on old kernels; modern ones ignore it.

Making it permanent

Option A, /etc/fstab:

10.20.30.5:/volume1/data  /mnt/nasdata  nfs4  rw,hard,timeo=600,retrans=2,_netdev  0  0

_netdev delays the mount until the network is up. On a server where the NAS may not be reachable at boot, an unreachable hard mount in fstab can stall the boot. That is where option B is better. I use B on anything that must boot unattended; a server hanging at boot because the NAS was rebooting is not fun.

Option B, systemd automount, which mounts on first access and unmounts when idle:

10.20.30.5:/volume1/data  /mnt/nasdata  nfs4  rw,hard,noauto,x-systemd.automount,x-systemd.idle-timeout=600,_netdev  0  0

Then sudo systemctl daemon-reload and sudo systemctl start mnt-nasdata.automount.

Ownership

Check what the client sees:

ls -ln /mnt/nasdata
id

If files show as owned by 1026 and your user is 1000, you have the UID mismatch. The Synology users start at UID 1026, and the users group is GID 100. Three ways to handle it:

  1. Create the client user with a matching UID (useradd -u 1026 -g 100 svc).
  2. Use "Map all users to admin" squash on the export and accept that everything is owned by admin.
  3. Enable "Apply default UNIX permissions" on the NFS service, which makes the NAS honour classic mode bits alongside its ACLs.

For a web server writing uploads, option 1 is the cleanest.

Did it work?

mount | grep nasdata
sudo touch /mnt/nasdata/nfs-test && ls -l /mnt/nasdata/nfs-test
nfsstat -m

nfsstat -m shows the negotiated version and options, and confirms vers=4.1 or 4.0. On the NAS side, sudo cat /etc/exports lists the generated export line; sudo exportfs -v shows what is live.

Errors

  • mount.nfs4: access denied by server while mounting 10.20.30.5:/volume1/data: the client's IP is not covered by an NFS rule, or the path is wrong. Note that a rule for 10.20.30.0/24 will not match a client coming through a VPN on 10.99.0.x.
  • mount.nfs: Connection timed out: the DSM firewall is blocking 2049 (or 111 and mountd for v3). Add the NFS application to the firewall profile.
  • Writes fail with Permission denied although the export is Read/Write: the squash setting mapped your user to guest, and the folder is not writable by guest. Change the squash or the folder ACL.
  • Every file appears as nobody:nogroup over NFSv4 while numeric IDs match: the NFSv4 domain differs between client and NAS. Set Domain = example.com in /etc/idmapd.conf on the client to match the NAS setting, then systemctl restart nfs-idmapd on CentOS or rpc.idmapd on Ubuntu.

Keep exports restricted to specific hosts. NFS with sec=sys trusts whatever UID the client claims, so a rule that says "everyone" is effectively a public share.