External NFS server configuration

Sharing data inside the same account is automatic — the platform handles both ends. Sharing data across accounts, or with a client outside the PaaS, requires configuring both sides explicitly. This page covers the server side: turning a Shared Storage Container into an NFS server reachable from external clients.

The same procedure works for any NFS-based storage server you operate; we describe it in terms of the platform’s Shared Storage Container.

1. Attach a public IP

External clients need a route to the server. Attach a public IP to the Shared Storage Container so it has a stable external address. Without it, the container is only reachable from inside the account.

2. Declare the exports

Edit /etc/exports on the storage container. The configuration manager surfaces this file under Exports → Configuration. The format is one share per line:

{directory} {client}([option],[option],...)

• {directory} — absolute path to the folder to export, relative to the container’s filesystem root.
• {client} — IP or hostname of the client that should be allowed to mount. You can use a wildcard or a subnet for multiple clients.
• [option] — access flags. The common ones are:
  • async — let the server reply to write requests before the data is flushed. Faster, with a small risk of loss on crash.
  • ro / rw — read-only / read-write.
  • no_root_squash — keep root on the client as root on the server. Use only with full trust.
  • no_subtree_check — skip the subtree integrity check. Faster but coarser.

If you cannot give the client a public IP — say, you are testing — you can use the host IP of the client container instead. This is insecure because it exposes the share to every container on that host. Do not use this in production.

3. GlusterFS storage clusters

If the storage container is a Shared Storage auto-cluster on GlusterFS, only the /data folder is replicated between cluster members. Exported directories must sit under /data.

You also need an fsid option on each export so NFS gives the share a stable file system ID across replicas. Generate one with:

cat /proc/sys/kernel/random/uuid

and append ,fsid={uuid} to the export line.

4. Apply the new exports

Reload the exports table:

exportfs -ra

Until you run this, the changes in /etc/exports are not active.

5. Open the firewall

NFS needs three ports open to the client IP:

• 111 (portmapper)
• 2049 (NFS itself)
• 20048 (mountd)

You can open them from the dashboard under Settings → Firewall, or with iptables over SSH:

iptables -I INPUT -p tcp -m multiport --dports 111,2049,20048 -s {client_ip} -j ACCEPT
iptables -I INPUT -p udp -m multiport --dports 111,2049,20048 -s {client_ip} -j ACCEPT

Restrict the source to the actual client IP. A blanket 0.0.0.0/0 rule on these ports is the wrong default — NFS is not built for the open internet.

6. Match the UIDs

When the client mounts with read-write, the UID/GID of the process writing on the client side must match permissions on the server side. Containers ship with different default users — root on some stacks, jelastic on others.

If the user on the client does not match, the writes will fail with permission errors. Adjust the ownership of the export folder on the server:

chown {uid}:{gid} {path}

where:

• {uid} is the user name or ID — check /etc/passwd on the client container.
• {gid} is the group name or ID — check /etc/group on the client container.
• {path} is the exported directory.

7. Optional: hosts.allow / hosts.deny

For additional control over which hosts the NFS server replies to, you can configure /etc/hosts.allow and /etc/hosts.deny. This is independent of the iptables rules and gives you a second layer of filtering at the NFS protocol level.

Where to go from here

• Mount points — configuring the client side to mount this export.
• External NFS storage — when the data lives on a third-party NFS server and you only need to mount it.
• NFS — protocol notes and limitations that apply to both client and server.