In Ubuntu Server environments utilizing the ZFS file system, the zfs-share.service is a systemd unit responsible for automatically exporting ZFS file systems as network shares (typically over NFS or SMB) during the boot process, based on the sharenfs or sharesmb properties set on the datasets. While this automatic sharing is convenient for dedicated NAS (Network Attached Storage) appliances, it is highly undesirable on secure compute nodes, database servers, or virtualization hosts. On these systems, accidentally setting a share property on a dataset could inadvertently expose sensitive local data to the network upon the next reboot. For maximum security, network sharing should be handled explicitly by dedicated daemon configuration files (like /etc/exports or smb.conf) rather than implicitly via ZFS dataset properties.
This guide explains how to completely disable the zfs-share.service in Ubuntu Server, ensuring that ZFS never automatically exports datasets to the network.
Stop and Mask the zfs-share Service
To ensure systemd completely ignores the automatic share directive and prevents ZFS from interacting with the NFS or Samba server processes during boot, we must aggressively disable and mask the service.
- Log into your Ubuntu Server via SSH using an account with
sudoprivileges. - First, stop the service if it is currently running (though its primary action is usually at boot):
sudo systemctl stop zfs-share.service - Next, disable the service to prevent it from hooking into the default boot sequence:
sudo systemctl disable zfs-share.service - Finally, to guarantee that the service cannot be accidentally triggered by another ZFS dependency (like a pool import), mask it entirely:
sudo systemctl mask zfs-share.service
Verify the Service Lockdown
By masking the service, you have instructed systemd to symlink the unit file to /dev/null, effectively treating it as a black hole.
To verify the lockdown is successful, run the following command to check the status of the service:
systemctl status zfs-share.serviceThe output will clearly state that the service is masked. If you reboot the server, you can be confident that even if a ZFS dataset has the sharenfs=on property applied, the ZFS daemon will not execute the necessary commands to register that share with the kernel NFS server on boot. You have successfully hardened your server against unintended network exposure via ZFS properties.