When mounting NFS, network error – 53 may appear. In this latest blog, we’ll seek answers to the questions such as what does the error means, what cause the error, and how we fix the error easily. As part of our Windows Support Service, Bobcares provides answers to all of your questions.
Overview
- What Is Network Error – 53 When Mounting NFS?
- Common Causes and Fixes for Network Error 53
- Conclusion
What Is Network Error – 53 When Mounting NFS?
Network Error – 53 is a common issue encountered when trying to mount an NFS (Network File System) share on Windows. This error occurs when Windows is unable to locate the specified NFS server or share, often causing frustration for users trying to access shared files across networks. The root of this problem can stem from various causes, such as incorrect configuration, missing components, or network issues.
Here, we will break down the potential causes of Network Error – 53 and provide simple fixes to help the user resolve the issue and successfully mount the NFS shares on a Windows system.
When we try to mount an NFS share on a Windows machine and face Network Error 53, the associated message will typically read: “The network path was not found.” This indicates that Windows cannot locate the NFS server or the shared directory on the network. The syntax for mounting an NFS share in Windows typically looks like this:
For example:
mount \\192.168.1.100\data N:
If this command fails, there are several potential causes and corresponding fixes.
Common Causes and Fixes for Network Error 53
1. Incorrect NFS Server Address or Share Name
Cause: The IP address or share name specified in the mount command may be incorrect.
Fix: Verify the correct IP address and share name by using the command showmount -e on the NFS server. This command lists the available NFS shares on the server. We must use the correct path in the mount command.
2. NFS Client Not Installed on Windows
Cause: The NFS client feature may not be installed on your Windows machine.
Fix: Install the NFS client by enabling the “Services for NFS” feature. To do this, we must run the following steps:
i. Go to “Control Panel” > “Programs” > “Turn Windows features on or off.”
ii. Scroll down and check the box for “Services for NFS.”
iii. Click “OK” and let Windows install the necessary components.
3. Firewall or Network Issues
Cause: Firewalls on either the NFS server or the Windows client may be blocking the necessary network ports required for NFS communication.
Fix: Temporarily disable the firewalls on both the server and client to see if this resolves the issue. If it does, configure the firewall to allow NFS traffic. Specifically, we need to allow port 2049 for NFS and port 111 for RPC traffic. Also, make sure these ports are open in both the Windows firewall and on the NFS server’s firewall.
Subscribe to our newsletter for the latest updates, news, and features.
4. Network Provider Order on Windows
Cause: Windows may prioritize other network providers over the NFS client, which can cause the NFS mount to fail.
Fix: Modify the network provider order in the Windows Registry with the following steps.
i. Open “Registry Editor” (press Win + R, type regedit, and press Enter).
ii. Then, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order.
iii. Modify the ProviderOrder value to prioritize NFS. The value should start with Nfsnp,RDPNP,LanmanWorkstation.
iv. Restart the system to apply the changes.
5. DFS (Distributed File System) Client Interference
Cause: The DFS client may interfere with NFS mounts, leading to Network Error 53.
Fix: Disable the DFS client in the Windows Registry with the below steps.
i. Open “Registry Editor.”
ii. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup.
iii. Create a new DWORD (32-bit) value named DisableDfs and set its value to 1.
iv. Restart the system to disable DFS and try mounting the NFS share again.
6. Permissions Issues
Cause: The user account trying to mount the NFS share may not have the necessary permissions on the NFS server.
Fix: Ensure that the correct permissions are set on the NFS server. To check permissions:
i. Log in to the NFS server and run ls -ld /path/to/nfs/share. This command will show the permissions for the shared directory.
ii. If the user or group trying to access the share doesn’t have proper permissions, adjust the access control.
iii. Also, verify the /etc/exports file on the NFS server, which defines the directories shared via NFS:
bash /path/to/nfs/share (rw,sync,no_subtree_check)
iv. After modifying the /etc/exports file, refresh the NFS exports with the following command:
exportfs -ra
7. NFS Configuration Errors
Cause: Misconfigurations in the NFS server setup could be preventing access.
Fix: Open the /etc/exports file on the NFS server and verify the syntax for each share entry. Make sure the paths are accurate and there are no typos or syntax errors. After making changes to the file, restart the NFS service to apply the new configuration:
sudo systemctl restart nfs-server
Or, if we’re using an older system:
sudo service nfs restart
We can also use the showmount -e command to ensure the shares are correctly configured and accessible.
[Want to learn more? Click here to reach us.]
Conclusion
Network Error 53 when mounting NFS shares on Windows can be caused by several factors, from incorrect server addresses to firewall issues or even NFS client installation problems. By systematically troubleshooting the potential causes, such as verifying server information, checking firewall configurations, and ensuring proper user permission, we can resolve this error and successfully mount the NFS share.
It’s always a good practice to ensure that all systems involved in NFS sharing are correctly configured and that any necessary services or features are enabled on both the server and the client. Our Tech team also suggests to keep the system up to date and regular setup checks to prevent future issues when working with NFS shares in a mixed Windows and Linux environment.
Skip to content
Hi everyone
If you find yourself with such error when you try to map a network drive in NFS;
Network Error – 53
Type ‘NET HELPMSG 53’ for more information
Please know that some tips exist to diagnose the error.
1- Make sure the NFS client is installed on the Windows 10.
2 – Make sure to use that registry fix if the mapping is on a restricted port;
HKLM\Software\Microsoft\ClientforNFS\CurrentVersion\Default\
UseReservedPorts := 0 (or 1) – DWORD32
3 – Make sure to use that registry fix to match the mapping GID/UID;
HKLM\Software\Microsoft\ClientforNFS\CurrentVersion\Default\
AnonymousGid := XXXX (usually 1001)
AnonymousUid := XXXX (usually 1001)
4 – In the linux server, make sure the /etc/exports is setting the insecure option.
NFS server has an option of working in insecure mode (Allowing higher incoming port numbers). Windows NFS client often uses higher port numbers. You can enable this option by adding an option to the share
Example: /share *(insecure,rw) ¹
As you can see it’s generic tips and of course disabling each firewall can’t hurt to diagnose 🙂
-
#1
I have been looking for a resolution to this issue, but I haven’t come up with much. I used the guide posted on the following site to setup the NFS client on Windows 10:
I get it all setup, but it never works. I always get a ’53’ error saying that the network path was not found. However it is correct. I have the same NFS share mounted in Ubuntu, and it works fine. It just doesn’t work in Windows. I am not sure what would cause the issue.
Here is my NFS config:
server IP is 192.168.0.24
NFS Share Path is /mnt/Tower
The only option I have enabled is ‘All Directories’
I have ‘Mapall User’ and ‘Mapall Group’ set to a specific user and group that exists on FreeNAS.
On the Windows machine I have installed the NFS client feature and the uid/gid setup in the registry for the user from FreeNAS for the Anonymous GID/UID setting. I have rebooted multiple times since setting that value.
The command I am using in Windows to map the drive is:
mount -o nolock anon \\192.168.0.24\mntT\Tower X:
No matter what I do I get «Network Error — 53»
I have tried disabling my firewall on my Windows machine and I get the same error.
As I stated at the beginning, the exact same NFS share is able to be mounted from Ubuntu just fine, so I think it has to be something on Windows, but I am not sure what else to try.
Any assistance would be appreciated. Let me know if there is any info that you need to assist with coming up with a fix.
Thanks in advance!
-
#3
mount -o nolock anon \\192.168.0.24\mntT\Tower X:
Just for fun, put the path in quotes or try it without the space (TowerX).
-
#4
I tried quotes and that resulted in the same error. I tried removing the space, but that just resulted in an error saying that i had to provide a drive letter «X:» to be mapped.
-
#5
There is an extra «T» after mnt so it ends up being mntT\Tower
Maybe a typo but could be a problem as well if you are copy/pasting. It’s simple to look over and could be an issue. Also in the adapter properties make sure that NFS is checked and move it up in the list to the top above the Microsoft Networks.
-
#6
I tried quotes and that resulted in the same error. I tried removing the space, but that just resulted in an error saying that i had to provide a drive letter «X:» to be mapped.
Doh, I see.
-
#7
@nightshade00013 I made the modifications to the network adapter, but it had no effect. Also, the extra «T» was a typo. Still not sure what is causing it to not work like it should.
Mirfster
Doesn’t know what he’s talking about
-
#8
What do you get when you simply use?:
Mount \\192.168.0.24\mnt\Tower X:
Mirfster
Doesn’t know what he’s talking about
-
#10
@Mirfster , I get the same error when I simplify the command. Also, I did adjust the provider order, but that didn’t have any effect.
Mirfster
Doesn’t know what he’s talking about
-
#11
@Mirfster , I get the same error when I simplify the command. Also, I did adjust the provider order, but that didn’t have any effect.
In all honesty, I truly do not know if a non-enterprise version of Windows does properly support NFS. Not calling the author of the article a liar, just that with MS things tends to change a lot under the hood and what may have worked for v1607, may not hold true for v1703, v1709, etc…
If you have access to an Enterprise version of Windows or a Server Version (2008 R2 should suffice); then maybe try that on a test machine to see if you can connect.
On a side note, is there a driving reason that NFS is needed/required? Just curious…
-
#12
I have tried it from Server 2016 Datacenter Edition and I get the same error.
I am just trying to get everyone moved over to one share type and the users that I have using SMB/CIFS are the most problematic.
Mirfster
Doesn’t know what he’s talking about
-
#13
Hmm, I don’t recall having much of an issue in the past. However, I am running FreeNAS v9.10…
I do have a system that I could try some stuff on, but it is ~2 weeks into seeding a huge backup to CrashPlan and I really really don’t want to mess with it until its done.
BTW, did you ever mention the version you are running?
0
2
я понимаю что жуткий офтоп, но может кто сталкивался?
стоит нфс под сентос 5.7. шарится линуксовыми клиентами на раз-два.
#cat /etc/exports
/opt/backup/share *(ro,sync,no_root_squash)
ставлю Win2003 R2.
C:\>mount IpNfsServer:/opt/backup/share Z:
Ошибка сети - 53
C:\>net helpmsg 53
Не найден сетевой путь.
в логах на нфс сервере следущее
mountd[3097]: refused mount request from 192.168.1.23 for /opt/backup/share (opt/backup/share): illegal port 1116
причем каждый раз долбится в разные порты, а где в винде ковырять отверткой не пойму…
psю виндовский файрвол отключен полностью