Migrate NFS Shares
to or from any cloud.
Any NFS export — Linux file server, NetApp, Isilon, AWS EFS, Synology, QNAP — is reachable to Mover through the Agent running on a Linux or macOS host that mounts the export.
Mover is the one-time cloud migration tool from Files.com — built for moving data between 20+ cloud providers and any on-prem storage reachable through the Files.com Agent. For NFS, that means installing the Agent on a host that can reach the NFS share, then pointing Mover at any of the supported cloud destinations on the other side.
When teams migrate NFS
The common situations.
Three or four real triggers below. Decommissioning aging hardware, consolidating into a cloud, tiering cold data to discount storage, or running hybrid setups where both sides need to stay in sync — the NFSside runs through the Agent; the cloud side runs through Mover's native connectors.
Decommissioning a Linux file server into the cloud
Aging Linux NFS servers moving to S3, GCS, Azure Blob, or other cloud destinations as part of a data center consolidation or cloud migration.
Migrating off enterprise NFS appliances
NetApp, Isilon, and similar appliances exporting NFS — the same Agent setup that handles a general Linux file server handles these too, since the protocol is the same.
Pulling cloud data into an NFS share for compute or analytics
Reverse direction: replicating cloud datasets to a high-throughput NFS share for compute clusters, render farms, or local analytics that need lower-latency access than the cloud provides.
Setup
4 steps to first dry run.
The Agent installs and configures the same way regardless of the source — what changes is the mount or share path it reads from. For the full Agent install reference, see the Files.com Agent page.
Mount the NFS export on a Linux or macOS host.
mount -t nfs <host>:<export-path> /mnt/nfs (or via /etc/fstab for persistence). The host needs read or write access matching the migration direction.
Install the Files.com Agent.
Download the Linux Agent from your Mover account. Install as a systemd service.
Configure the Agent root at the mount path.
In the Agent TOML config, set root to /mnt/nfs (or wherever the export is mounted). Choose permission_set based on direction.
Dry run, launch, monitor.
Connect the Agent in Mover, run a dry run for the exact byte total and cost, launch the migration. The Agent reads or writes through the standard Linux NFS stack.
Common Questions
Frequently asked.
Specific to NFS. For the broader Agent FAQ (auto-update, logging, bandwidth limits, etc.), see the Files.com Agent page.
NFSv3 vs NFSv4 — which works?
Both. The Agent reads through the kernel's NFS client; whichever version the export uses is fine. NFSv4 with Kerberos auth is supported as long as the Agent host can authenticate.
What about NFS user mapping (UID/GID)?
The Agent runs as the user it was installed as. Make sure that user (or the service account) has read or write access on the NFS export — most NFS deployments use either no_root_squash for service accounts or explicit UID mapping. Set this up before the Agent runs.
Can the Agent run on the NFS server itself?
Yes, technically. Install the Agent on the file server, point its root at a local directory (which is the same path the NFS export serves). Avoids the network hop. Just make sure the Agent doesn't compete with the NFS service for disk I/O during business hours.
What about NFS-exported AWS EFS or Google Filestore?
Works. Mount the EFS or Filestore export on an EC2 / GCE instance, install the Agent there, configure the root. The Agent treats it like any other NFS mount.
Reached through the Files.com Agent
NFS Shares migrations run the same way as every other Agent setup.
The Agent is the same component across every on-prem or network-share source. Install once, point at a path, migrate to any of the 20+ Mover destinations.
Run a dry run before any data moves.
Connect NFS via the Agent, run a free dry run, see the exact size, file count, and price.