nfs file server

Sign in to the Azure portal, select Create a resource, and search the Marketplace for NFS File Server by SecureAnyCloud. Select the listing, then select Create.

On the Basics tab, choose your subscription, resource group, region and VM size (Standard_B2s or larger). Under Administrator account, select SSH public key, set the username, and paste your public key. Under Inbound port rules, allow SSH (22) for administration. You add the NFS rule (TCP 2049), scoped to your client subnets, after deployment.

On the Disks tab, review the dedicated data disk. It is included in the image and holds your shared data. Select Review + create, then Create. First-boot initialisation completes within a few seconds of the VM reaching the Running state.

Create a VM from the SecureAnyCloud NFS File Server image in an existing VNet and subnet. Replace the values in angle brackets with your own. The dedicated /srv/nfs data disk is part of the image and is attached automatically.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:nfs-file-server-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name nfs-file-server \
  --image sac1647283583153:nfs-file-server-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
# Allow NFS (TCP 2049) from your client subnet only — never from the internet.
az vm open-port --resource-group <your-rg> --name nfs-file-server --port 2049 --priority 1010

Connect to the VM over SSH as the administrator user you set at deploy time (azureuser by default on Ubuntu). The administrator account accepts SSH keys only.

ssh azureuser@<vm-public-ip>

The NFS server starts automatically on boot. Confirm that the service is active, that it serves NFSv4 only, that the dedicated data disk is mounted, and inspect the live export table.

systemctl is-active nfs-server.service cat /proc/fs/nfsd/versions findmnt -no SOURCE,SIZE,FSTYPE,TARGET /srv/nfs
sudo exportfs -v

The versions line shows -3 +4, which means NFSv3 is disabled and NFSv4 is enabled. The export table lists /srv/nfs/share restricted to 127.0.0.1, which is the secure default.

Read the first-boot information file and the export summary with the nfs-share tool. The file records the server's private IP and the exact command to open the share to your clients.

sudo cat /root/nfs-server-info.txt
sudo nfs-share status

The image ships with the share exported to 127.0.0.1 only. This is deliberate: no client on the network can mount the share until you explicitly allow its network. The image never ships a wildcard (*) or 0.0.0.0/0 export.

The export uses these options:

• root_squash maps a remote root user to the unprivileged nobody account.
• sync commits writes before the server acknowledges them.
• no_subtree_check keeps exports stable and reliable.

Grant a trusted client network read/write access to the share with nfs-share allow, passing a CIDR range or a single host. Use your own client subnet's CIDR in place of the example value. Add --ro for a read-only export.

sudo nfs-share allow 10.0.0.0/24
sudo nfs-share list

The tool appends the export, reloads the export table and confirms the change. It refuses world-open exports: nfs-share allow '*' and nfs-share allow 0.0.0.0/0 are both rejected, and so is the --no-root-squash option. You cannot accidentally expose the share to the whole internet or give remote root full ownership.

On a client machine in the allowed network, install the NFS client tools and mount the share using the server's private IP address, which is recorded in /root/nfs-server-info.txt. NFSv4 mounts the exported path directly.

# On the client (Ubuntu/Debian):
sudo apt-get update && sudo apt-get install -y nfs-common
sudo mkdir -p /mnt/nfs
sudo mount -t nfs <server-private-ip>:/srv/nfs/share /mnt/nfs
# Verify and use it:
df -h /mnt/nfs echo "hello from the client" | sudo tee /mnt/nfs/test.txt

To mount the share automatically at boot, add this line to the client's /etc/fstab.

<server-private-ip>:/srv/nfs/share /mnt/nfs nfs defaults,_netdev 0 0

You can confirm the export works end to end on the server itself, without any client. A loopback mount over 127.0.0.1 writes a file, reads it back and unmounts.

sudo mkdir -p /mnt/nfs-check
sudo mount -t nfs 127.0.0.1:/srv/nfs/share /mnt/nfs-check echo "sac NFS shared storage" | sudo tee /mnt/nfs-check/hello.txt cat /mnt/nfs-check/hello.txt
sudo rm -f /mnt/nfs-check/hello.txt
sudo umount /mnt/nfs-check

A successful write and read-back confirms that the server, the export and the dedicated data disk are all working.

Use the nfs-share tool to inspect, add and remove client networks. It is the primary interface to the export allow list.

sudo nfs-share status
sudo nfs-share list

Revoke a client network's access when it no longer needs the share. The export table reloads immediately.

sudo nfs-share deny 10.0.0.0/24

The tool supports these commands:

• nfs-share status shows the server, the configured clients and the live export table.
• nfs-share list shows the live NFS export table (exportfs -v).
• nfs-share allow <CIDR\|host> [--ro] grants a client network read/write access, or read-only access with --ro.
• nfs-share deny <CIDR\|host> revokes a client network's access.

You can also edit /etc/exports directly and run sudo exportfs -ra to apply changes. The nfs-share guardrails apply only when you use the tool.

Shared data lives on a dedicated Azure data disk mounted at /srv/nfs, separate from the OS disk. The exported directory is /srv/nfs/share. Because the disk is captured in the image, every VM you deploy has it automatically.

To grow the share, resize the data disk in the Azure portal or CLI, then extend the filesystem.

# After increasing the data disk size in Azure:
sudo growpart /dev/disk/azure/scsi1/lun0 1 2>/dev/null || true
sudo resize2fs $(findmnt -no SOURCE /srv/nfs)

The export root /srv/nfs/share is owned by the unprivileged nobody:nogroup account. Clients writing through root_squash can therefore read and write, and the mount is never world-writable.

The image is hardened out of the box:

• The server runs NFSv4 only, so rpcbind and statd are not present and the only listening port is TCP 2049.
• The shipped export is loopback-only until you open it.
• Every export uses root_squash, so remote root has no privileged access.
• The nfs-share tool refuses world-open exports.

To keep the server locked down, scope the NSG rule for TCP 2049 to the client subnets that need the share, and never expose port 2049 to the internet. Grant the narrowest CIDR ranges you can, prefer --ro exports for read-only consumers, and keep the OS patched (sudo apt update && sudo apt upgrade). For sensitive data over untrusted networks, consider Kerberos (sec=krb5p) or a private, encrypted network path.

Subscribe to the product in AWS Marketplace, then select Continue to Launch. Choose your instance type (an m5.large is a sensible starting point), your VPC and subnet, and your EC2 key pair. Attach a security group that allows inbound TCP 22 from your administrator network.

You do not need to open port 2049 to launch. Add that rule when you are ready to let clients mount the share, and scope it to your client subnets only.

The image provisions a dedicated data volume for the export automatically, so you do not need to attach one manually. For a larger share, increase the size of that data volume at launch or grow it later.

You can also launch from the command line. Replace the AMI ID, key name, subnet and security group with your own values.

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key \
  --subnet-id subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=nfs-file-server}]'

Connect to the instance with your EC2 key pair. The default login user for the Ubuntu variant is ubuntu.

ssh -i my-key.pem ubuntu@<public-ip>

For the Ubuntu 24.04 variant of this listing, the SSH login user is ubuntu.

The first boot writes the server details to a root-only file. Read it to see the export path, the server's private IP and the exact commands to open the share.

sudo cat /root/nfs-server-info.txt

The file lists the export path (/srv/nfs/share), the server's private IP, the NFS protocol (NFSv4 over TCP 2049) and the default export options.

Check that the NFS server is running, then review the current export policy with the bundled nfs-share tool.

systemctl is-active nfs-server.service
sudo nfs-share status

On a fresh instance, the status shows the server as active, the export directory as /srv/nfs/share, and the loopback address 127.0.0.1 as the only configured client. That is the secure default: nothing on the network can mount the share yet.

Before you open the share to the network, confirm that it works end to end. Mount it over the loopback address, write a file and read it back.

T=$(sudo mktemp -d /mnt/nfs-check.XXXX)
sudo mount -t nfs 127.0.0.1:/srv/nfs/share "$T" echo "sac-nfs-check" | sudo tee "$T/check.txt"
sudo cat "$T/check.txt"
sudo rm -f "$T/check.txt"
sudo umount "$T"
sudo rmdir "$T"

The file you write appears in the exported directory and reads back byte for byte. The export uses root_squash, so the client's root is mapped to an unprivileged account. The export root is owned by that account, so writes succeed while the mount is never world-writable.

The exported directory lives on a dedicated data volume, separate from the operating system disk. You can resize or snapshot your data without touching the OS. Check the volume with this command.

findmnt -no SOURCE,TARGET,FSTYPE,SIZE /srv/nfs

The mount is backed by its own filesystem and is mounted by filesystem UUID through /etc/fstab, so the layout is stable across reboots and re-launches.

The share is loopback-only until you allow a trusted network. On the server, run nfs-share allow with the CIDR of the subnet your clients run in.

sudo nfs-share allow <your-mgmt-cidr>

Add --ro to grant read-only access instead of read/write.

sudo nfs-share allow <your-mgmt-cidr> --ro

Review and revoke access at any time.

sudo nfs-share list
sudo nfs-share deny <your-mgmt-cidr>

The tool refuses to export to * or 0.0.0.0/0 and refuses --no-root-squash, so a slip cannot silently open the share to the internet. Grant only the specific networks you trust.

You must also allow the traffic at the network layer. Add an inbound rule for TCP port 2049 to the instance's EC2 security group, scoped to your client subnets. The export allow list and the security group are two independent controls, and both must permit a client before it can mount.

On a client host in an allowed network, install the NFS client tools (sudo apt-get install -y nfs-common on Debian/Ubuntu, or sudo dnf install -y nfs-utils on RHEL family), then mount the share using the server's private IP.

sudo mkdir -p /mnt/nfs
sudo mount -t nfs <private-ip>:/srv/nfs/share /mnt/nfs

To mount the share automatically at boot, add this line to the client's /etc/fstab.

<private-ip>:/srv/nfs/share /mnt/nfs nfs defaults,_netdev 0 0

The image is hardened by design:

• Secure by default. The shipped export is restricted to the loopback address, so a fresh instance shares nothing on the network until you open it.
• NFSv4 only. NFSv2 and NFSv3 are disabled, so rpcbind and rpc.statd are not required and the only listening port is TCP 2049. This removes a whole class of legacy NFS attack surface.
• root_squash. A client connecting as root is mapped to an unprivileged account, so remote root cannot own or overwrite arbitrary files.
• Two independent controls. The export allow list (nfs-share) and the EC2 security group both gate access. Keep the security group rule for port 2049 scoped to your client subnets.
• No world-open export. The nfs-share tool refuses *, 0.0.0.0/0 and --no-root-squash as hard guardrails.

The export lives on its own EBS data volume, so you can manage storage independently of the OS. Take EBS snapshots of the data volume for point-in-time backups, and restore a snapshot to a new volume when you need to. As your data grows, grow the volume and then extend the filesystem. None of this affects the operating system disk.

The nfs-share tool is the primary interface to the server.

sudo nfs-share status
sudo nfs-share list

• nfs-share status shows the server state, the export directory and the configured client networks.
• nfs-share list shows the live export table.
• nfs-share allow <cidr> [--ro] grants a trusted network access.
• nfs-share deny <cidr> revokes a network's access.