VPC NAS mount fails for cross-region access, returns permission denied error on mount attempt

Cloud Platforms Alibaba Cloud
, , , , , , , ,
1

We’re trying to mount a NAS file system from ECS instances in a different region using VPC peering, but the mount operation fails with permission denied errors. The NAS is in Region A (Shanghai), and we need to access it from ECS instances in Region B (Beijing) for our disaster recovery setup.

VPC peering is established between the two regions and shows as “Active” status. Network connectivity is confirmed - we can ping the NAS mount target IP from Region B instances. But when we attempt to mount using NFS protocol, it fails:

mount -t nfs -o vers=3 192.168.1.100:/nas-share /mnt/remote-nas
mount.nfs: access denied by server while mounting 192.168.1.100:/nas-share

The NAS access rules are configured to allow the VPC CIDR from Region A, but maybe cross-region requires different configuration? We’ve checked NAS Console permissions and the mount target is set to VPC type. Has anyone successfully mounted NAS across regions using VPC peering? What access rule configuration is needed for cross-region NFS mounts?

2

One thing people often miss - when you add a new access rule to a NAS permission group, it can take 1-2 minutes to take effect. After adding the Region B CIDR, did you wait a bit before retrying the mount? Also, double-check that the permission group you edited is actually the one attached to the mount target you’re trying to access. Some NAS file systems have multiple mount targets with different permission groups.

3

I added the Region B VPC CIDR (172.16.0.0/16) to the NAS permission group, but still getting permission denied. The VPC peering routes look correct - I can reach other services in Region A from Region B. Could there be firewall rules blocking NFS traffic specifically? Or does NAS have additional cross-region restrictions I’m missing?

4

Cross-region NAS access via VPC peering requires careful configuration of multiple components. Let me walk through the complete setup and troubleshooting process.

Architecture Overview: When mounting NAS across regions using VPC peering:

• NAS mount target exists in Region A VPC (192.168.0.0/16)

• ECS instances in Region B VPC (172.16.0.0/16)

• VPC peering connects the two VPCs

• NFS traffic flows through peering connection

Required Configuration Steps:

1. NAS Access Rules (Critical)

The NAS permission group must explicitly allow the Region B VPC CIDR:

NAS Console → File Systems → Select your NAS → Permission Groups → Edit:

• Add rule: IP Address = 172.16.0.0/16 (Region B VPC CIDR)

• Permission: Read/Write

• User Permission: no_squash (preserves user IDs)

• Priority: 1 (higher priority than other rules)

Wait 2-3 minutes after adding the rule before testing - changes aren’t instant.

2. VPC Peering Route Configuration

Verify routes exist in both directions:

Region A VPC route table:

• Destination: 172.16.0.0/16 (Region B)

• Next Hop: VPC peering connection

Region B VPC route table:

• Destination: 192.168.0.0/16 (Region A)

• Next Hop: VPC peering connection

3. Security Group Rules

Region B ECS security group (outbound):

• Allow TCP/UDP port 2049 (NFS)

• Allow TCP/UDP port 111 (RPC portmapper)

• Allow TCP/UDP ports 1024-65535 (NFS dynamic ports)

• Destination: 192.168.1.100/32 (NAS mount target IP)

Region A mount target security group (if applicable):

• Allow inbound from 172.16.0.0/16 on same ports

4. NFS Mount Command

Use these mount options for cross-region mounts:

mount -t nfs -o vers=3,nolock,proto=tcp,noresvport,rsize=1048576,wsize=1048576 192.168.1.100:/nas-share /mnt/remote-nas

Key options explained:

• vers=3: Use NFSv3 (more reliable for cross-region)

• nolock: Disable file locking (reduces network round-trips)

• proto=tcp: Force TCP protocol (more stable than UDP for long-distance)

• noresvport: Don’t use privileged source ports (helps with NAT/peering)

• rsize/wsize: Large buffer sizes for better throughput

Troubleshooting Steps:

Step 1: Verify Network Connectivity From Region B ECS:

telnet 192.168.1.100 2049
telnet 192.168.1.100 111

Both should connect. If telnet fails, issue is network layer (routes/security groups), not NAS permissions.

Step 2: Check RPC Services

rpcinfo -p 192.168.1.100

Should list NFS services. If this fails, RPC ports are blocked.

Step 3: Test with Verbose Mount

mount -vvv -t nfs -o vers=3 192.168.1.100:/nas-share /mnt/remote-nas

Check output for specific error (authentication, protocol, permission).

Step 4: Verify Permission Group Assignment NAS Console → Mount Targets → Check which permission group is attached to the mount target at 192.168.1.100. Ensure it’s the group you edited.

Common Issues:

Issue 1: Wrong Permission Group Solution: NAS file systems can have multiple mount targets, each with different permission groups. Verify you edited the correct group for the mount target IP you’re accessing.

Issue 2: Security Group Blocking RPC Solution: NFS requires multiple ports. Many admins only open 2049, forgetting port 111 and dynamic ports. Open full port range 111-65535 for testing, then narrow down.

Issue 3: NFSv4 vs NFSv3 Solution: Cross-region mounts work better with NFSv3. If you’re using vers=4 or auto-negotiation, force vers=3.

Issue 4: Source IP Not Matching Rule Solution: The NAS sees the source IP as the ECS instance’s private IP in Region B. Use ip addr show on the ECS to confirm its IP, then verify that IP falls within the CIDR range you added to the NAS access rules.

Performance Considerations:

Cross-region NAS mounts have higher latency than same-region:

• Shanghai ↔ Beijing: ~30-40ms latency

• Throughput limited by inter-region bandwidth

• Use larger rsize/wsize (1MB) to reduce round-trips

• Consider async mount option for write-heavy workloads

For disaster recovery, evaluate if you need real-time access or if periodic sync (rsync/ossutil) would be more efficient.

Alternative Architecture:

If cross-region NAS mount performance is inadequate:

• Use OSS for cross-region data replication (OSS Cross-Region Replication)

• Mount NAS locally in each region, sync via scheduled jobs

• Use CEN (Cloud Enterprise Network) instead of VPC peering for better inter-region bandwidth

Your Specific Issue:

Based on your error, most likely causes:

  1. The Region B CIDR (172.16.0.0/16) is not in the NAS permission group, OR
  2. You added it to the wrong permission group (not the one attached to mount target 192.168.1.100), OR
  3. Security group is blocking port 111 (RPC portmapper)

Verify permission group assignment first, wait 3 minutes after adding the rule, then test with the full mount command including all options I provided above.

5

Try mounting with verbose output to see exactly where it’s failing. Use the mount command with -v flag and check system logs. Sometimes the error is more specific than just “permission denied” - could be protocol version mismatch, RPC authentication failure, or mount target not reachable. Also verify your NFS client version is compatible with the NAS service version.

6

NAS access rules are based on IP address ranges, not VPC IDs. If your Region B ECS instances have IPs in a different CIDR block than Region A, you need to add those IPs to the NAS access rules. Check what source IP the mount request is coming from when you try to mount from Region B - it’s probably not in your allowed IP list.

7

Check your security group rules on both sides. NFS uses port 2049 for the primary connection, but it also needs portmapper (port 111) and random high ports for RPC. Make sure your Region B security group allows outbound to these ports, and Region A security group (if attached to the mount target VPC) allows inbound. Also verify the mount target type - it should be VPC type, not Classic network.