Original_Vecna

Can we get this updated? It's been over a year now since any updates.

Where's the fix on this? This continously happens. I'm on 6.12.13 and this has happened to me a couple times over the past year and there's NOTHING to do to fix it but a reboot, and that is NOT acceptable.

Needed to add: 192.168.1.79(rw,sec=sys,insecure_locks,sync,no_root_squash) Added the NFS share direct in my docker container, removing the extra mounting of nfs share in the linux system, and handling it direct in docker-compose. Works PERFECT now! Thanks again!

At this point I don't think it has anything to do with you...I just don't know why all of a sudden this is happening. If I run: dd if=/dev/zero of=/mnt/frigate_nfs/testfile bs=1M count=100 on the frigate server, it writes just fine, and if I spam it, unraid UD writes increment like they should. So the UD nfs share IS working...it's like Frigate forgot what to do. I've rebooted the server, verified the share is mounted properly, can touch and otherwise right to the share... Real noodle scratcher.

@dlandon Hate to be a pain, but every since I got the new UD, and was abled to enable the NFS share for my UD, I'm having REALLY poor connection issues to it. My frigate server just isn't writing to it. The drive goes to sleep, Home assistant feeds are hit or miss, just really bad. I could previously sit on the Main Unraid page and watch the writes climb every sec with writes from my 10 cctv cameras. Now? It barely increments. This wasn't happening when I was juggling mounting previously. The service was excellent, it was the reliability that I occasionally had issues with. ( Dropping connection )

Great to hear it wasn't me. LOL Thank you so much! This has been a thorn in my side for some time now.

@dlandon That did it! If I may ask...what was wrong with my server?

YOU ARE MY HERO! THANK YOU!

ud_diagnostics-20240507-115037.zip tomcat-diagnostics-20240507-1155.zip Here ya go! Thank you so much!

Got the SUCCESS message, but when I went back into UD, and changed the NFS export to Yes, then Apply, page refreshed and it was set to No. Same thing. I can't even change the name from Dev1. Nothing will stick.

Can anyone help please? I thought I had a work around, but the dang server keeps having issues. Keeps dropping NFS shares. I can't get the option to enabled NFS shares in unassigned devices to stay YES. I set it to yes, the page refreshes, and it's back to no.

Thanks, that's exactly what I'm trying to do. When I do it, I click apply. The page refreshes, and the option is back to No. Again, when I do that, the name and options of my disk in Unassigned Devices resets completely. Automount, share, and the name "frigate" reverts to dev1 and the options are lost. Syslog gives me: Apr 27 11:25:40 server1 unassigned.devices: Warning: Unassigned Devices are not set to be shared with NFS. Apr 27 11:25:54 server1 ool www[10136]: /usr/local/emhttp/plugins/unassigned.devices/scripts/rc.settings 'nfs_settings' Apr 27 11:25:54 server1 unassigned.devices: Updating share settings... Apr 27 11:25:54 server1 unassigned.devices: Share settings updated.

Correct. But in the shares screen, it's listed like this, that's what I was referring to. Which is what they were set to.

That is exactly what I had done originally before changing to cache only. Brought down docker ( had no vms actively running ) the shares already were cache <---Array. So I instituted the mover. Checked the syslog, and nothing was copied over. Changed to cache only. Restarted docker. I ended up moving libvirt.img from /mnt/user/system to /mnt/cache/system and the fix common problems error about system having files still on the array went away. But the NFS share for unassigned drives is still chooched. I was able to force it up temporarily by adding the entry to /etc/exports, but I'd prefer to get it working natively, as exports tends to wipe itself clear of any modifications.

I am currently running 2024.04.22 Attached is the ud_diagnostics Thank You! ud_diagnostics-20240427-163444.zip