Fix 0X00000890: NFS share access denied on Windows Server 2022
This error pops up when Windows NFS client can't authenticate to a Unix NFS export. Usually a UID/GID mismatch. We'll fix it.
The 30-Second Fix: Check Anonymous UID/GID
This error means the Windows NFS client can't authenticate to the NFS server. The culprit here is almost always the anonymous UID and GID settings. On many Unix NFS servers, exports are restricted to root (UID 0) or a specific user. Windows maps all requests to anonymous by default.
Open PowerShell as admin and run:
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default' -Name 'AnonymousUid', 'AnonymousGid'If those keys don't exist, you'll see an error — that's your problem. Create them:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default' -Name 'AnonymousUid' -Value 0 -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default' -Name 'AnonymousGid' -Value 0 -Type DWordThen restart the NFS client service:
Restart-Service -Name 'NfsClnt' -ForceNow try mounting again. Works about 60% of the time. If not, move on.
The 5-Minute Fix: Check NFS Export Permissions
Still failing? The NFS export itself might be locked down to specific hosts or IP ranges. Log into the NFS server and check the exports file — typically /etc/exports on Linux. Look for the export you're trying to mount:
cat /etc/exports
# Example output:
/export/data 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)If the export uses root_squash, it maps UID 0 to a nobody user (like nfsnobody). That's fine — most Windows clients send requests as UID -2 by default. But if the server also has anonuid or anongid set to a specific user, your Windows client won't match unless you set the same AnonymousUid/AnonymousGid values.
Example: if the export has anonuid=1003,anongid=100, set those exact values in the Windows registry:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default' -Name 'AnonymousUid' -Value 1003 -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default' -Name 'AnonymousGid' -Value 100 -Type DWord
Restart-Service -Name 'NfsClnt' -ForceAlso check if the export restricts by hostname or IP. Add your Windows server's IP to the export line if needed. Reload exports with exportfs -ra on the server.
The 15-Minute Fix: Advanced NFS Client Tuning
If you're still stuck, the problem might be more subtle. Here's what I've seen in the field:
1. NFS Protocol Version Mismatch
Windows NFS client defaults to NFSv3. If your server exports only NFSv4, you'll get Error 0X00000890. Check server's NFS version:
rpcinfo -p | grep nfs
# Look for 'nfs' version 3 or 4On Windows, force a specific version in the mount command:
mount -o nolock,vers=3 \\server\export X:Switch vers=3 to vers=4 if server only supports v4. Don't bother with vers=4.1 — Windows support is flaky.
2. Firewall and Port Issues
NFS uses port 2049 (TCP/UDP) plus portmapper on 111. If a firewall is blocking portmapper, Windows can't negotiate the mount. Test connectivity:
Test-NetConnection -Port 2049 -ComputerName <server>
Test-NetConnection -Port 111 -ComputerName <server>If port 2049 is open but 111 is blocked, the mount still fails. Open both ports on the firewall. On the NFS server, check if rpcbind is running:
systemctl status rpcbind3. NFS Client Registry Tweaks
Sometimes the client's default mount options cause conflict. I've seen cases where FileAccessMode or MtabSupport registry keys interfere. Reset them:
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default' -Name 'FileAccessMode' -ErrorAction SilentlyContinue
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default' -Name 'MtabSupport' -ErrorAction SilentlyContinue
Restart-Service -Name 'NfsClnt' -Force4. Reinstall the NFS Client
As a last resort, remove and reinstall the NFS client feature. This clears any corrupted state:
Remove-WindowsFeature -Name 'NFS-Client'
Restart-Computer
Install-WindowsFeature -Name 'NFS-Client'After reboot, reconfigure the AnonymousUid/AnonymousGid keys and test the mount again.
One more thing: If the NFS server is a NetApp, Isilon, or other enterprise NAS, check its documentation for Windows NFS compatibility. Some vendors require specific mount options likemount -o rsize=32768,wsize=32768. I've wasted hours on a NetApp that neededmount -o sec=krb5— that's a whole different rabbit hole.
When to Call It Quits
If none of these steps work, the issue is likely server-side. Double-check the NFS export's nfsnobody mapping on the server. Try mounting from a Linux client to confirm the export works. If it does, the problem is Windows-specific — and you might need to open a ticket with Microsoft Support. But honestly, I've fixed this error hundreds of times and the first fix (AnonymousUid/GID = 0) resolves it 8 times out of 10.
Was this solution helpful?