When attempting to mount an NFS4 share, the "No such device" error typically occurs due to mismatches between server exports configuration and client mount commands. Let's examine the complete workflow and proper configuration.

The /etc/exports file requires careful attention to NFS4-specific parameters:

# /etc/exports configuration for NFS4
/export        *(ro,sync,fsid=0,crossmnt,no_subtree_check)
/export/workspace *(rw,sync,no_subtree_check,no_root_squash)

Key differences from NFS3:

• fsid=0 marks the root of NFS4 pseudo-filesystem
• crossmnt allows clients to traverse mount points
• Avoid mixing NFS3 options like insecure with NFS4

The correct mount syntax for NFS4 differs significantly from NFS3:

# Proper NFS4 mount command
sudo mount -t nfs4 -o proto=tcp,port=2049 server-ip:/ /mnt/nfs

# For workspace specifically
sudo mount -t nfs4 -o proto=tcp,port=2049 server-ip:/workspace /mnt/workspace

When encountering "No such device" errors:

1. Verify NFS services are running on server:

   sudo systemctl status nfs-server
   sudo rpcinfo -p | grep nfs

2. Check client NFS module:

   lsmod | grep nfs
   modprobe nfs

3. Test basic connectivity:

   rpcinfo -t server-ip nfs
   showmount -e server-ip

For complex environments, consider these adjustments:

# Server /etc/nfs.conf additions
[nfsd]
vers4=y
vers4.0=y
vers4.1=y
vers4.2=y

# Client /etc/fstab entry
server-ip:/workspace  /mnt/workspace  nfs4  rw,hard,intr,tcp,timeo=600,retrans=2  0  0

NFS4 requires these ports open:

# iptables rules for NFS4
sudo iptables -A INPUT -p tcp --dport 2049 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 2049 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 111 -j ACCEPT

Remember to persist firewall rules after testing.

---

When working with NFSv4 mounts, the "No such device" error typically indicates either a protocol version mismatch or incorrect export path specification. In this specific case, we're seeing the error when attempting to mount a workspace directory from an NFS server to a client machine.

Several factors could contribute to this error:

• Incorrect export path formatting in /etc/exports
• Missing or incorrect fsid parameter
• Client attempting NFSv4 mount while server only supports older versions
• Firewall blocking NFS communication

First, let's examine the server configuration we're working with:

# /etc/fstab entry
/home   /export none    bind

# /etc/exports entries
/export     *(ro,sync,no_subtree_check,insecure,fsid=0)
/export/workspace   *(rw,sync,no_subtree_check,insecure,nohide)

This configuration appears mostly correct, but let's verify the NFS server version:

# Check NFS server version
cat /proc/fs/nfsd/versions

The original mount command was:

sudo mount -t nfs4 192.168.145.131:/workspace nfs/ -v

Let's improve this with explicit options:

sudo mount -t nfs4 -o vers=4.2,proto=tcp,timeo=5,retrans=5 192.168.145.131:/workspace /mnt/nfs

If the above doesn't work, try these variations:

# Try with explicit export path
sudo mount -t nfs4 192.168.145.131:/export/workspace /mnt/nfs

# Try legacy NFSv3
sudo mount -t nfs -o vers=3 192.168.145.131:/export/workspace /mnt/nfs

Verify what services are actually being exported:

rpcinfo -p 192.168.145.131

You should see entries for nfs, mountd, and nlockmgr.

Ensure these ports are open:

# NFSv4 uses TCP port 2049
# For NFSv3, additional ports are needed:
# portmapper (111), mountd (random), nlockmgr (random)

Here's a verified configuration that works:

# Server /etc/exports
/export/workspace 192.168.145.0/24(rw,sync,no_subtree_check,fsid=1)

# Client mount command
mount -t nfs4 -o vers=4.1 192.168.145.131:/workspace /mnt/nfs