Let me provide a comprehensive solution for resolving NFS mount issues with IBM Cloud File Storage.
Root Cause Analysis:
The ‘access denied by server’ error with IBM Cloud File Storage typically results from a combination of NFS export permissions, security group configuration, and mount command syntax issues.
NFS Export Permissions:
IBM Cloud File Storage uses IP-based access control lists (ACLs) to determine which hosts can mount an NFS export. Critical requirements:
-
Authorized Hosts Configuration:
- Navigate to Storage > File Storage in IBM Cloud console
- Select your volume and find ‘Authorized Hosts’
- Add your VSI’s private IP address (not public IP)
- Format: Individual IP (10.240.0.15) or subnet (10.240.0.0/24)
- Changes propagate within 1-2 minutes
-
IP Address Verification:
- On your VSI, run:
ip addr show or `ifconfig
- Use the IP from the private network interface (usually eth0 or ens3)
- Verify this exact IP is in the authorized hosts list
- Subnets must match: /32 for single host or appropriate CIDR for range
Security Group Configuration:
Security groups in IBM Cloud VPC act as virtual firewalls. For NFS connectivity:
-
Required Outbound Rules:
Protocol: TCP, Port: 2049, Destination: 10.0.0.0/8
Protocol: TCP, Port: 111, Destination: 10.0.0.0/8
Protocol: UDP, Port: 111, Destination: 10.0.0.0/8
-
Why These Ports:
- Port 2049: Primary NFSv4 communication
- Port 111: RPC portmapper for NFS handshake
- 10.0.0.0/8: IBM Cloud private network range (includes file storage endpoints)
-
Common Mistake:
- Not having a default ‘allow all outbound’ rule
- Forgetting to apply security group changes to the VSI
- Using public IP ranges instead of private network ranges
Mount Command Syntax:
The correct mount command format for IBM Cloud File Storage:
sudo mount -t nfs4 -o sec=sys,vers=4.1 \
fsf-dal1001a-fz.adn.networklayer.com:/IBM01SEV123456_1 \
/mnt/data
Key Parameters:
-t nfs4: Specifies NFSv4 protocol-o sec=sys: Uses standard Unix authenticationvers=4.1: Explicitly sets NFS version (recommended)- Mount path: Use exact path from console (case-sensitive, no escaping needed)
- Local mount point: Must exist before mounting (
mkdir -p /mnt/data)
Troubleshooting Steps:
- Verify Network Connectivity:
ping fsf-dal1001a-fz.adn.networklayer.com
telnet fsf-dal1001a-fz.adn.networklayer.com 2049
If telnet fails, security group rules are blocking traffic.
2. **Check NFS Client:**
```bash
# Ensure NFS client is installed
sudo yum install nfs-utils -y # RHEL/CentOS
sudo systemctl start rpcbind
sudo systemctl enable rpcbind
- Test Mount with Verbose Output:
sudo mount -t nfs4 -o sec=sys,vers=4.1,rw,bg,hard,timeo=600,rsize=65536,wsize=65536 \
fsf-dal1001a-fz.adn.networklayer.com:/IBM01SEV123456_1 /mnt/data -vvv
The `-vvv` flag provides detailed error information.
4. **Verify Mount Success:**
```bash
df -h | grep /mnt/data
ls -la /mnt/data
Permanent Mount Configuration:
Add to /etc/fstab for automatic mounting on boot:
fsf-dal1001a-fz.adn.networklayer.com:/IBM01SEV123456_1 /mnt/data nfs4 sec=sys,vers=4.1,rw,bg,hard,timeo=600,rsize=65536,wsize=65536,_netdev 0 0
The _netdev option ensures the mount waits for network availability.
Complete Resolution Checklist:
- [ ] VSI private IP added to File Storage authorized hosts
- [ ] Security group allows TCP 2049 and TCP/UDP 111 outbound
- [ ] Security group changes applied to VSI
- [ ] NFS client packages installed (nfs-utils)
- [ ] rpcbind service running
- [ ] Local mount point directory exists
- [ ] Mount command uses correct hostname and export path from console
- [ ] NFSv4.1 explicitly specified in mount options
Expected Timeline:
- Authorized host changes: 1-2 minutes
- Security group changes: Immediate
- Mount operation: 5-10 seconds
After following these steps systematically, your file storage mount should succeed. If issues persist, check IBM Cloud status page for any file storage service disruptions in your region, and verify that your file storage volume status is ‘Active’ in the console.