Morning, all my barebone systems (Rocky Labserver, MX Linux, 2xDebian Pi4) can connect to the Rocky Mainserver NFS, and the Mainserver can connect to the Labserver NFS. All are using eth0. The Labserver has a bridge0 to eth0.
On the Labserver using bridge0, I created a Window 10 Pro VM for office duties;
- I can not connect to the Mainserver NFS,
- I can connect via ssh,
On the Windows,
- CMD: I keep getting “The network path was not found”
- Explorer: Diagnostics - “Windows can’t communicate with the device or resource (IP)” and it goes on to say “It is available but not responding to connection attempts. A firewall or network security policy on the remote computer might be blocking the connection on port ‘file and print sharing resource’”
On the Mainserver exports file I do have the Windows IP.31:
/media/KbbnNFS02 IP.12(rw,async) IP.10(rw,async) IP.29(rw,async) IP.31(rw,async)
What else do I need to fix this?
You have installed NFS support under Windows I assume?
Yes, Services for NFS and also the SMB 1.0/CIFS File Sharing Support, SMB Direct was already enabled.
The Windows error “The network path was not found”, probably also with the NET HELPMSG 53 would suggest that the share is not accessible - either because the incorrect sharename was provided, or it doesn’t have access to it.
I’ve mounted a share from my Synology system without any problems on Windows 10. What OS is the Mainserver running that has NFS Server installed on it?
And after editing /etc/exports, did you restart the NFS server or reexport the /etc/exports file?
It’s Rocky
Yes, but i checked my history and did a exportfs -av, just did a redo with -rv and results the same.
I’m using the same case name and path as its on the server: “\\IP.15\media\KbbnNFS02”
for Windows does there need to be additional options to (rm, async) and/or does the folders need additional attributes?
Alternately for now, I just installed Reminna and just map the path to in the settings until I find the solution as to why I can’t connect to the NFS.
Last time I checked, Win10 client only offers NFS 3.x, not NFS 4.x
Maybe this is the reason? I believe Rocky defaults to 4.x, not sure if its configured to backport? Do I need to make changes to add 3.x support?
Unless I’m mistaken, it will work for nfs3 and nfs4 normally by default. You can test enough by doing this on Linux. If it mounts then NFS3 is available:
mount -o vers=3 nfs-server:/share /mnt/nfs
that’s just an example, you’ll need to adapt it to your requirements in terms of share and mountpoint. If that works, then it should work for Windows.
The other thing to check is if firewalld is running on Rocky Linux - maybe you didn’t allow that particular IP address to access the server. That can also be checked by just stopping firewalld and then try to mount under Windows.
From my MX Linux | Labserver (Rocky), this was the response:
root@mxkohan:/mnt# mount -o vers=3 IP.15:/media/KbbnNFS02 /mnt/nfs
mount.nfs: requested NFS version or transport protocol is not available
So I’m assuming its not available, then what changes if any do I need to make?
Look at /etc/nfs.conf, you’ll see a section like this:
[nfsd]
# debug=0
# threads=8
# host=
# port=0
# grace-time=90
# lease-time=90
# udp=n
# tcp=y
# vers3=y
# vers4=y
# vers4.0=y
# vers4.1=y
# vers4.2=y
rdma=y
rdma-port=20049
You’ll prob have to uncomment the versions that you want to mount. And then restart nfs-server service.
1 Like
Thanks and I found the problem, the vers3 was uncommitted (I believe I did this early after install, but forgot to comment it back) and init to “n”… And while were in the nfs.conf, is it ok to remove all comments and have them initialed to “y” and nfs functions properly?
You usually just uncomment and use what you need. So unless you need to uncomment and use the options, just leave them commented.
1 Like