DietPi only connects to NFSv3 share (not NFSv4.x)

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | 9.11.2
  • Distro version | bookworm
  • Kernel version | 6.1.0-31-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1
  • Architecture | amd64
  • SBC model | Virtual Machine (x86_64)
  • Power supply used | n/a
  • SD card used | SSD (virtual disk from Proxmox)

Additional Information (if applicable)

  • Software title | dietpi-drive_manager

Steps to reproduce

  1. Try to connect a new NFS share via dietpi-drive_manager

Expected behaviour

  • Successfully connected to NFS share

Actual behaviour

  • No NFS share found

Extra details

  • NFS share is provided by OpenMediaVault
  • DietPi successfully connects to NFS share if NFSv3 is supported
  • If only NFSv4.x is supported, DietPi does not detect any NFS share
2

Maybe our blog gives some impressions to investigate a bit more.

Especially the issue around fsid=0 could be looked at.

3

The issue around fsid=0 described in the blog post applies in case DietPi is the NFS server, right? In this case, OpenMediaVault is the NFS server and DietPi is the NFS client trying to connect.

I can’t find anything in the blog post that would hint why it only works with NFSv3 but not with NFSv4.x. The blog post even mentions that NFSv4 is the better version to use.

4

Have you checked the openmediavault site for clues, for example here.
https://forum.openmediavault.org/index.php?thread/47163-omv-without-nfs-v4-server/

5

My question is, how the exports file of the OMV is set. Depending on the fsid=0
Could you please post it here?

I would like to check this section of the blog post:

Remark: If fsid=0 is used in the exports file (former DietPi versions), it means that the <path_to_directory> is the directory point which shall be the root of exported directories: If several directories with at least one subordinated directory shall be exported, e.g. with different options, the uppermost directory is given the fsid=0 (equal to fsid=root) attribute.
Additionally, the mount command on the client has to direct to / instead of /mnt/dietpi_userdata in the /etc/fstab file.

Can you also post the output of exportfs (server side) and showmount -e <server_hostname> (client side)?

6

It seems that this issue is caused by a 3rd party plugin, as mentioned here?

7

As I had no idea what options to use, I decided to simply use the same options that DietPi is using when creating an NFS share. These are:
async, crossmnt, no_root_squash, no_subtree_check, rw

When I enter the commands you mentioned, I can see all shares on both sides. So no issues here.

1 Like
8

@RyoShinzo : And can you now mount the NFS share via NFS v4?

To “learn” more about OMV, can you share the options which OMV generates?

9

I think what I learned was that there is a certain way the share must be mounted. I believe @StephanStS is wondering how exactly the OMV sets up the server and what mounts are presented to the client.
I doubt you would have that third party plugin installed on your system or do you?

1 Like