Can't login after removing NFS share

Troubleshooting
1

I have an NFS share that I changed the naming convention in the /etc/exports from /mnt/HDD to /mnt/Seagate. Afterwards I added this drive to a different DietPi PC to reflect the changes. This PC had both NFS mount points so I tried removing the old one through dietpi-drive_manager. It gave me a warning that the share was not empty so I backed out with the escape key. Despite doing so, the old share was removed from the NFS client. I browsed the folders that were contained in the share and it appears the files were intact.

I rebooted the client PC and now I am unable to login via ssh or console through physically plugged in keyboard. I tried CTRL+C, return, CTRL+Alt+F2, and rebooting. I did change the dietpi.txt timezone from the default one to my local one but not sure if this is the root cause. This is the output

Stopping Network Time Synchronization... 
[ OK ] Stopped Network Time Synchronization.
Starting Cleanup of Temporary Directories... 
[ OK ] Started Cleanup of Temporary Directories.
A start job is running for NFS server and services (16min 46s/no limit)
2

did you tried to login via SSH?

3

Yes, via ssh it says the connection refused to connect. The PC is connected via Ethernet and does show an IP address on the dietpi banner.

4

You could try booting of a Linux Live USD stick. This way you should be able to get access to data located on your original HDD and check settings within fstab configuration file.

6

After using a live USB to remove all NFS mount points I can login but as soon as I add the NFS mount point on the client and reboot I am back at square one with the initial error of not being able to login.

Here are my NFS server exports

/mnt/Seagate (rw, async,no_root_squash, fsid-0, crossmnt,no_subtree_check)

/mnt/Seagate/Media (rw, async, no_root_squash, fsid=0,crossmnt,no_subtree_check)

And the client fstab

#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------
192.168.1.62:/mnt/Seagate /mnt/Seagate nfs nofail, noauto, x-systemd.automount

#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=1883M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------


#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
UUID=5925cd3a-efbe-4b41-bc03-b2b369e7f9ab / ext4 noatime,lazytime,rw 0 1
UUID=8780-C205 /boot/efi vfat noatime,lazytime,rw 0 2
7

There is a typo, but idk if this can cause the problems you have.

8

I used google image recognition to copy and paste the text, that is the reason for the typo. I verified via ssh and the typo is not there.

9

can you remove this one from NFS export on server side. Restart NFS server afterwards.

10

No dice. Removing the line had no effect. I use the same fstab NFS entry on an Arch Linux Desktop and it mounts with no problems.

I tried using NFS 4 and setting a timeout. The timeout is not respected and the system continues to hang.

192.168.1.62:/mnt/Seagate /mnt/SeagateNFS nfs4 timeo=60,nofail,auto,x-systemd.automount

Also tried forwarding port 2049 on the server per a Opensuse article suggestion.

root@DietPi:~# rpcinfo -p | grep nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100003    3   udp   2049  nfs
11

how does it behave if you mount the NFS share manually? Are you able to access the share afterwards?

12

I am able to access the share through the terminal, but when trying to access the share through Plex it does not show it as available. It was working before with the below docker Plex config. I gave access to all volumes in /mnt to the container. Tried restarting the docker container using docker restart plex, as well as using dietpi-services. Also deleted the plex container and recreated it.

-v /mnt:/mnt \

mount -t nfs 192.168.1.62:/mnt/Seagate /mnt/Seagate

docker run
-d
–name plex
–restart unless-stopped
–network=host
–restart=always
-p 32400:32400/tcp
-e VERSION=latest
-e PUID=1000 -e PGID=1000
-e TZ=America/Chicago
-e PLEX_CLAIM=claim-xxxxxxxxxxxxxxxxxxx
-v /home/docker/plex/transcode:/transcode
-v /docker/containers/plex/config:/config
-v /mnt:/mnt
–device=/dev/dri:/dev/dri
plexinc/pms-docker:plexpass

13

ok this is confusing now. The issue is within the Docker container? And not on the host system?

14

The issue with the system hanging using an NFS fstab entry is with the host system.

The issue with the Plex container not seeing mounted volumes might be due to the docker container. I did have this working before using the same docker config and fstab entries.

15

But the mount is working the moment you attach it? It’s not hanging that moment? Only on reboot?

Did you try the whole thing without Plex Docker container? Means to remove that container/config for testing.

16

It doesn’t hang when manually mounting using the mount command or fstab, it only hangs upon reboot after adding the fstab entry. I can see the contents of the share using the terminal with both methods

I disabled docker using dietpi-services and after adding the drive using dietpi-drive_manager the hanging issue persists.