0

On Microsoft Windows Failover Cluster (Windows Server 2019 Datacenter) I've created a File Server role and created a NFS share (similar to how it's described in these instructions). The idea was to mount this share from a virtual machine running Linux (Ubuntu)

The problem is that Linux (Ubuntu) times-out when trying to mount this share:

admin@ubuntu-server:/mnt$ sudo mount -o nolock -v -t nfs 192.168.1.16:/nfs /mnt/nfs/
[sudo] password for admin:
mount.nfs: timeout set for Fri Jul  1 08:22:43 2022
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.1.16,clientaddr=192.168.1.74'
mount.nfs: mount(2): Connection timed out
mount.nfs: Connection timed out

Further inspection revealed that this File Server does not listen on port 2049/tcp:

admin@ubuntu-server:/mnt$ sudo nmap 192.168.1.16
Starting Nmap 7.80 ( https://nmap.org ) at 2022-07-01 07:12 UTC
Nmap scan report for 192.168.1.16
Host is up (0.00037s latency).
Not shown: 995 filtered ports
PORT     STATE SERVICE
111/tcp  open  rpcbind
135/tcp  open  msrpc
445/tcp  open  microsoft-ds
2179/tcp open  vmrdp
3389/tcp open  ms-wbt-server
MAC Address: A0:36:9F:34:39:26 (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 4.91 seconds

The next step was to try to verify if Linux can in fact mount and NFS-type share created on Windows system. So on the same Windows Server I created folder on local disk and shared it by activating NTF sharing option (in folder properties).

Linux (Ubuntu) was able to mount this share without problems:

admin@ubuntu-server:/mnt$ sudo mount -o nolock -v -t nfs 192.168.1.11:/test2 /mnt/test2/
mount.nfs: timeout set for Fri Jul  1 07:11:58 2022
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.1.11,clientaddr=192.168.1.74'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'nolock,vers=4.1,addr=192.168.1.11,clientaddr=192.168.1.74'

admin@ubuntu-server:/mnt$ ll test2/
total 5
drwxrwxrwx 2 nobody 4294967294   64 Jun 15 13:02 ./
drwxr-xr-x 3 root   root       4096 Jul  1 07:08 ../
-rwxrwxrwx 1 nobody 4294967294   11 Jun 15 13:03 README.txt*

So I checked the server's IP for open ports which revealed port 2049/tcp to be open:

admin@ubuntu-server:/mnt$ sudo nmap 192.168.1.11
Starting Nmap 7.80 ( https://nmap.org ) at 2022-07-01 07:12 UTC
Nmap scan report for windows-server.our-domain (192.168.1.11)
Host is up (0.00047s latency).
Not shown: 993 filtered ports
PORT     STATE SERVICE
111/tcp  open  rpcbind
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs             <---------- PORT IS OPEN
2179/tcp open  vmrdp
3389/tcp open  ms-wbt-server
MAC Address: A0:36:9F:34:39:26 (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 4.42 seconds

I've compared how the two shared are configured and the configuration is identical apart the following:

  • one is running in failover cluster while the other is running directly on windows
  • one is using local folder while the other is using a disk from the cluster storage
  • the clustered File server has it's own IP address, while the NFS share done in Windows is accessible via OS's IP address

Now I'm pretty much out of options. Can anyone help?

Here if further info on my system:

  • Failover cluster is running on Windows Server 2019 Datacenter
  • cluster uses a Fiber Channel-connected storage
  • we're using Ubuntu Server 20.04
knee-cola
  • 221
  • 1
  • 6

1 Answers1

0

We have managed to solve this problem by using CIFS/SMB instead of NFS:

  • in Windows cluster we configured the File Server role to use Samba (instead of NFS)
  • in our Ubuntu machine we mounted the used CIFS to mount the volume

P.S. The goal of this exercise was to migrate away from using Ubuntu inside a virtual machine as NFS server for our Docker Swarm containers and replace it with a Windows Cluster's File Server role. This would eliminate the need of running a whole virtual machine for this role and will make the system administration much easier.

knee-cola
  • 221
  • 1
  • 6