When configuring NFS shares on AWS instances, you might encounter this specific error during export operations. The message indicates the NFS server can't properly resolve or validate the client's network address configuration.

# Typical problematic exports entry:
/opt/share1 ec2-50-16-224-79.compute-1.amazonaws.com(rw,async)

# Resulting error:
exportfs: internal: no supported addresses in nfs_client
domU-12-31-38-04-7E-02.compute-1.internal:/opt/share1: No such file or directory

Three primary factors typically cause this behavior:

• DNS resolution problems between NFS server and client
• Improper hostname formatting in /etc/exports
• AWS-specific network configuration requirements

Solution 1: Use IP Addresses Instead of Hostnames

# Replace with client's private IP
/opt/share1 172.31.15.203(rw,async,no_subtree_check)

Solution 2: Verify and Update Hosts File

# /etc/hosts should contain:
172.31.15.203 ec2-50-16-224-79.compute-1.amazonaws.com

Solution 3: AWS-Specific Configuration

# Ensure proper security group rules:
# Inbound: TCP/UDP 2049 (NFS) from client IP/security group
# Outbound: Ephemeral ports 32768-60999

1. After modifying /etc/exports, always run:

exportfs -ra

2. Verify proper sharing with:

showmount -e localhost

If issues persist, examine detailed NFS server logs:

tail -f /var/log/messages | grep nfs
rpcinfo -p

When configuring an NFS server on AWS EC2 instances running SLES11, you might encounter this cryptic error:

exportfs: internal: no supported addresses in nfs_client
domU-12-31-38-04-7E-02.compute-1.internal:/opt/share1: No such file or directory

The error actually combines two distinct issues:

1. Address resolution failure (no supported addresses)
2. Directory path issue (No such file or directory)

1. DNS Resolution Problems

The primary issue stems from NFS being unable to resolve the client's hostname properly. In AWS environments, this is particularly common when:

• Using public DNS names in /etc/exports
• Not properly configuring the VPC DNS settings
• Having reverse DNS lookup issues

2. Recommended Fixes

Here are the most effective solutions:

# Option 1: Use IP addresses instead of hostnames
/opt/share1 50.16.224.79(rw,async)

# Option 2: Use the internal AWS hostname format
/opt/share1 ip-10-0-0-1.ec2.internal(rw,async)

# Option 3: Add entries to /etc/hosts
50.16.224.79 ec2-50-16-224-79.compute-1.amazonaws.com

After making changes, always verify:

# Check exports
showmount -e localhost

# Test NFS functionality
mount -t nfs localhost:/opt/share1 /mnt/test

For AWS-specific NFS optimization:

# In /etc/sysconfig/nfs:
RPCNFSDARGS="-N 2 -N 3 -H 30"
RPCMOUNTDOPTS="-p 32767"
STATDARG="-p 32765 -o 32766"

When running NFS in AWS:

• Always use security groups to restrict access
• Consider using no_root_squash carefully
• Monitor via CloudWatch for unusual activity