Storage AWS

NFS File Server on AWS User Guide

Last updated: 2026-07-21 | Product: NFS File Server on AWS

Overview

This image runs a production ready network file server built on the operating system's own kernel NFS server, the file sharing standard trusted across Linux and Unix networks. The service is fully configured and security hardened, so you can share files across your trusted network within minutes of launch without hand editing exports or tuning the NFS daemon.

The exported directory is /srv/nfs/share, which lives on a dedicated, independently resizable storage volume mounted at /srv/nfs, kept separate from the operating system disk. Because the export lives on its own volume you can grow it, snapshot it, or back it up without touching the OS.

The image ships secure by default. The share is exported to the loopback address (127.0.0.1) only, so no client on the network can mount it until you explicitly allow your own client network. There is no wildcard export, no 0.0.0.0/0, no insecure option, and no no_root_squash in the shipped configuration. Root on a client is squashed to an unprivileged account, exports use sync and no_subtree_check, and the server is NFSv4 only so there is a single well known TCP port (2049) and no rpcbind or statd attack surface. A single management tool, nfs-share, is the primary interface to the server and refuses to open the share to the whole internet.

On the first boot of every deployed instance, a one shot service prepares the export directory, derives a per instance NFSv4 domain, reapplies the locked down export, and records the server details in a root only file at /root/nfs-server-info.txt, so you can confirm the server works immediately and then open the share to exactly the networks you trust.

Prerequisites

Before you deploy this image you need:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for administrator SSH access to the instance
A VPC and subnet in the target Region, with a security group allowing inbound TCP port 22 from your administrator network, and inbound TCP port 2049 from the client subnets that will mount the share
The AWS CLI version 2 installed locally if you plan to deploy from the command line, and one or more Linux clients on the same trusted network to mount the share

Step 1: Launch the Instance from the AWS Marketplace

Subscribe to the product in AWS Marketplace, then choose Continue to Launch. Select 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 once 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. If you want a larger share, increase the size of that data volume at launch or grow it later.

Step 2: Launch the Instance from the AWS CLI

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}]'

Step 3: Connect as the Administrator over SSH

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>

The Connecting to your instance table lists the SSH login user for each operating system variant of this listing:

Operating system variant	SSH login user
Ubuntu 24.04	`ubuntu`

Step 4: Review the Server Details

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

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

Step 5: Confirm the Service and Export Status

Check that the NFS server is running and review the current export policy with the bundled nfs-share tool:

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

Out of the box the status shows the server is active, the export directory is /srv/nfs/share, and the only configured client is the loopback address 127.0.0.1. That is the secure default: nothing on the network can mount the share yet.

Step 6: Prove the Share Works (Loopback Round Trip)

Before you open the share to the network you can prove it works end to end locally, by mounting it over the loopback address, writing a file, and reading it back:

T=$(sudo mktemp -d /mnt/nfs-check.XXXX)
sudo mount -t nfs 127.0.0.1:/srv/nfs/share "$T"
echo "cloudimg-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 on the exported directory and reads back byte for byte. Because the export uses root_squash, the client's root is mapped to an unprivileged account, and the export root is owned by that account so writes succeed while the mount is never world writable.

Step 7: Understand the Data Volume

The exported directory lives on a dedicated data volume, kept separate from the operating system disk, so you can resize or snapshot your data without touching the OS:

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

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

Step 8: Open the Share to Your Client Network

The share is loopback only until you allow a trusted network. Use nfs-share allow with the CIDR of the subnet your clients run in. Run this on the server:

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 to the instance's EC2 Security Group for TCP port 2049, scoped to your client subnets. The export allow list and the security group are two independent controls; both must permit a client before it can mount.

Step 9: Mount the Share from a Linux Client

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 automatically at boot, add a line to the client's /etc/fstab:

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

Step 10: The Security Model

This 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.

Step 11: Growing and Backing Up Storage

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

Step 12: Day to Day Operation

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.

Support

cloudimg provides 24/7 technical support for this NFS File Server product by email and live chat, with a one hour average response time for critical issues.

Email: support@cloudimg.co.uk
Live chat: available around the clock

We help with deployment and initial configuration on AWS, export policy and client access design, the NFSv4 only root_squash security model, mounting from Linux and Unix clients, data volume snapshots and resizing, and network file sharing architecture. New customers can request a free guided setup session covering instance launch, security group configuration for port 2049, and opening the export to your client network.