Score:0

NFS4 works on one server but not the other

in flag

I have 2 VMs, both running debian buster. One is a test VM, the other my production file server. On both I installed the nfs server package through "apt install". I created a share on the test VM called nfs under /mnt/nfs. This folder is owned by nobody:nogroup. In my exports file I have the following content:

/mnt/nfs *(rw,sync,no_subtree_check,no_root_squash,no_all_squash,insecure)

There is no volume or harddrive attached to this "mountpoint" it is just a directory. When I mount this folder on another machine through sudo mount -t nfs testVM:/mnt/nfs /mnt/disk the volume is mounted as NFS4!!!!! This is what I want and it is awesome. (obviously the "other" machine contains the nfs-common package so I can mount the share in the first place)

Now to my issue. On my production file server, on which the same packages are installed, there are 6 volumes (raid partitions) mounted. They are managed by the host (proxmox virtualization environment) and passed through to the VM. I added which folder I wanted to share in the exports file and exported these folders through exportfs -rav. As an example, I have shared the following folder:

/srv/test *(rw,sync,no_subtree_check,no_root_squash,no_all_squash,insecure)

Which was supposed to be a test to see if I share a folder without anything attached externally what would happen. Unfortunately that does not work and every time I am trying to mount an nfs share as NFS4 the mount reverts back to NFS3.

Whatever I am trying nothing gets mounted to any other VM or any other machine, for that matter, as an NFS4 share. Everything is just shared as NFS3, which I don't want as NFS4 supports additional features that I need in order to make other stuff work in my network (especially file locking).

Does anybody have any ideas why I am unable to us a NFS4 from my test machine but not from my production file server?

Sethos II avatar
jp flag
How do you try to mount the share from your production server? Have you tried adding an explicit version while mounting (`-o vers=4.2`) and what is the result?
realShadow avatar
in flag
@SethosII sorry for my late reply and thanks for yours. I tried to mount a share just now with `sudo mount -t nfs -o vers=4.2` and `sudo mount.nfs -o vers=4.2`. Obviously I used a mount that existed but I am getting the error `mount.nfs: mounting <IP>:/mnt/path failed, reason given by server: No such file or directory`.
Sethos II avatar
jp flag
Ok, try with just `<SERVER IP>:/path` without `/mnt`. Sadly there is no way to list available NFS exports on the client with NFS4. Before NFS4 you could use `showmount -e <SERVER IP>`. But the `No such file or directory` points to something with the path and if I remember correctly NFS4 changed the way how paths are shown to the clients.
realShadow avatar
in flag
@SethosII But how should that work? the /mnt is part of the path. The share is at /mnt/volume6/kubedata.
Sethos II avatar
jp flag
NFS4 has a concept of a root for the exports. Depending on where this is set you need to leave out the preceeding path. See `fsid` in the manpage of `exports`. You could test to set `fsid=0` as an option to your export and mount with `IP:/` without any path as it will use the exported directory with `fsid=0` as the root.
realShadow avatar
in flag
@SethosII thanks for the comment. I tried your suggestions but unfortunately without success. I have added a "root" path to the exports file with `/mnt/volume6 IP(rw,sync,fsid=0,no_subtree_check,no_root_squash,insecure)` but that also only mounted as a nfs3 version. At this point I only see 2 options. 1 create a new VM and transfer all the disks and functionality to that new machine or 2 just accept that the existing VM does not allow a NFS4 share. Everything I tried so far will not work unfortuantely.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.