kcossabo

correct, that is the symptom of unRAID not supporting this. This is a simple AB Test, tried 5 DAC Cables, one Fiber cable 4 switches, changed the OS and it works.

dockofthebay-diagnostics-20260628-2022.zip This is definitely a unRAID issue I have two identical servers, one with OPNsense one with unRAID, unRAID will not see the 10GE SFP ports, the other older version, was an unRAID server, never could get the SPF+ to work with unRAID, since I retired it from unRAID put Ubuntu on it, the SFP+ work great.

I have two Supermicro 5019D Server, 4C/8T Xeon D-2123T (Built on the X11SDV-8C-TP8F motherboard), one is setup as a OPNsense router and the other unRAID server. The OPNSense server SFP+ ports work with DAC cable to ubiquity no issues, unRAID build will not recognize them. root@DockOfTheBay:~# for i in /sys/class/net/eth*; do n=${i##*/}; \ printf "%-6s mac=%s " "$n" "$(cat $i/address)"; \ ethtool $n 2>/dev/null | grep -E "Speed:|Port:|Link detected:" | tr '\n' ' '; echo; \ done eth0 mac=3c:ec:ef:dd:48:56 Speed: 10000Mb/s Port: Twisted Pair Link detected: yes eth0.1 mac=3c:ec:ef:dd:48:56 Speed: 10000Mb/s Port: Twisted Pair Link detected: yes eth0.253 mac=3c:ec:ef:dd:48:56 Speed: 10000Mb/s Port: Twisted Pair Link detected: yes eth0.30 mac=3c:ec:ef:dd:48:56 Speed: 10000Mb/s Port: Twisted Pair Link detected: yes eth0.42 mac=3c:ec:ef:dd:48:56 Speed: 10000Mb/s Port: Twisted Pair Link detected: yes eth0.55 mac=3c:ec:ef:dd:48:56 Speed: 10000Mb/s Port: Twisted Pair Link detected: yes eth1 mac=3c:ec:ef:dd:3d:ba Speed: Unknown! Port: Twisted Pair Link detected: no eth2 mac=3c:ec:ef:dd:48:57 Speed: Unknown! Port: Other Link detected: no eth3 mac=3c:ec:ef:dd:3d:bb Speed: Unknown! Port: Twisted Pair Link detected: no eth4 mac=3c:ec:ef:dd:48:58 Speed: Unknown! Port: Other Link detected: no eth5 mac=3c:ec:ef:dd:48:59 Speed: 10000Mb/s Port: Direct Attach Copper Link detected: no eth6 mac=3c:ec:ef:dd:3d:bc Speed: Unknown! Port: Twisted Pair Link detected: no eth7 mac=3c:ec:ef:dd:3d:bd Speed: Unknown! Port: Twisted Pair Link detected: no root@DockOfTheBay:~# eth0 is the 10GbT connection and eth5 is the DAC. Thoughts how to turn it up? I saw some post on a melonox driver but have no reason to think this is mellonox. Switch side sees Up / connected, 10G full-duplex

FYI Version - 0.9.15.11 required me to change the PGID: from 100 to 1000 container was failing with addgroup: gid '100' in use adduser: unknown group cabernet su-exec: getpwnam(cabernet): Invalid argument addgroup: gid '100' in use adduser: unknown group cabernet su-exec: getpwnam(cabernet): Invalid argument Starting with UID : 99 Starting with UID : 99

Assumed Root Cause After 2 weeks of stability the assumed root cause is one of the following In compatibility with nVidia drivers and 7.1.4 - low probability as I assume there are a lot of installed and not having the issue In compatibility with nVidia drivers and 7.1.4 and other drivers and combinations on my server - higher probability as this get to more of a snowflake of some combination is causing the issue BAD nVidia card - high probability, as the removal did result in a stability. Though not crashing on earlier versions of unRAID. Each of these could be refined, but, not my jam to figure this out, just provide the family with stability.

When building the key, did not ‘think’ and used the standard / latest version (Server down for the upgrade of the USB DOM, working through the backup of the old key, and missed selecting the 6.x), and did an unintended upgrade. This was a 6.x to 7, and after the new DOM Key install, did not think the effort to go back right away (back to the server rack, unmount the server, open up the case, and remove the DOM from the mother board, back to the workstation, and build again) was worth it, it is the new stuff. Then the crashes started. If it this was immediate, and constant, I probably would have gone back. As you know the networking changed, and had a history of issues, moving down to a lower 7.x looked like a network issue risk, and after research the move back to 6.x looked risky after all the changes over the weeks of being at 7.x Was not an easy option, see above. Moving back in the 7.x introduces more known bugs, at the time of writing, there were no stated issues with nVIDIA and like most posted, assumed a memory issue, and worked it. Thank You - the stability of a DOM, also introduces the need for me to dive into the rack server, and pull the motherboard based USB drive. The upgrade was done by building a new key via the Mac Tool, for a new DoM after too many USB Stick failure. (Skip rant on the need to use a USB to boot a server). With 20+ Containers and this server being a key daily/hourly used services, going through a process like this was not an option. It would be if it crashed, after an hour, but it is days between them. So have a server (that is used hourly) down for a week, to feel comfortable it is ‘stable’ and layer the next fix on was not an option. I am extremely, extremely disappointed that there is so little diagnostic tools with this product that the guess work is the procedure to fix issues. I have a Syslog Server (SPLUNK), I have console Crash captures, and the best troubleshooting we have is, try this, or some ‘canned’ response of it is your memory. Working with two AI models, diagnosing 4 crashed console and SysLogs, everything pointed to the NVIDIA issue. Two weeks stability with the GPU and drivers gone. Moved the nVIDIA workloads to another server on a lower release, and have stability. (btw, why not move everything? The server with instability is Intel, with integrated GPU, that I use, the other servers are XEON and AMD and can not support the workloads). I do like the unRAID platform with three servers. The value it brings for both hosting and experimenting is great. Support on USB Failure is fast, I could not express how incredible getting support with in an hour on the weekend due to a USB Key failure is. Unfortunately I have learned. how fast the support is too many times. Not enterprise priced, not enterprise quality. PS. this post is over a month after the failures / crashes / ‘upgrade’ started, thus the frustration. Not sure who has the need for unRAID, and can support 5+ weeks of outages.. The good thing is not having a USB Drive, (holding back on the rant), and after too many server failures because of a $10 USB Stick, I built a DOM Based server that seems to be the community hive’s recommendation for stability. I was on a VERY VERY old version for the great advice you just mentioned. This Product is made great by great people like you willing to help. Thank You

Update. As suspected the server has become extremely stable with the Nvidia drivers and video card removed. Update. As suspected the server has become extremely stable with the Nvidia drivers and video card removed. With the removal of the Nvidia GPU and drivers the server has not failed with the removal of the With the removal of the Nvidia graphics card and associated drivers there hasn’t been a crash.

As stated, did the memory test for 10 hours clean Retest, is just wait until some unknown time to feel like the issue was the GPU, and then try it again........... The crashes were not "I did this, than that occurred" it is the server is down, oh crap, let me fix. In an effort for it to not crash I removed the nVidia drivers (as indicated), in a hope that I have stability until I return home this weekend. My assumptions are nvidia driver issue removed the drivers, so all the apps that use nvidia are not? I assume they will try CPU transcoding? or OLLAMA will just fail wait 4 days in this state if no crashes, then put them back in? Down grading the OS is my GUT move as it is the new OS that started this, but that does seem to have risk.

Server log from Syslog server (SPLUNK) and Diag, though I did remove the plugins before this was run. dockyard-diagnostics-20250908-0530.zip there are a lot of these Sep 7 20:51:46 10.10.9.1 Sep 7 20:51:46 DockYard kernel: NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0 Sep 7 20:51:46 10.10.9.1 Sep 7 20:51:46 DockYard kernel: NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x22:0x51:884) also Sep 7 20:54:18 10.10.9.1 Sep 7 20:54:18 DockYard kernel: #PF: supervisor instruction fetch in kernel mode Sep 7 20:54:18 10.10.9.1 Sep 7 20:54:18 DockYard kernel: BUG: unable to handle page fault for address: ffffffff824fc5c0 1757334860_88.csv.zip

Crash 9-7.pdfcrash 9-8.pdf Issue started when I upgraded the USB Key to a DoM and when building upgraded the server from 7.1.2 to 7.1.4 Issuetwo crashes in last 24 hours, three in the since upgrade 2 weeks ago Steps so farmemory test for 10 hours clean Put both screen grabs of the crash into ChatGPTThanks for sharing the second screenshot — this gives more detail. Here’s what’s happening: What the Trace ShowsThe panic here is in the RCU subsystem (Read-Copy-Update), which is a core Linux synchronization mechanism. Specifically: rcu: rcu_preempt kthread starved for 664912 jiffies! g=7744983 fqs=6 This means the RCU preempt kernel thread was stuck/starved for too long — the kernel watchdog considers this a deadlock. Backtrace shows: native_queued_spin_lock_slowpath raw_spin_lock resched_curr rcu_gp_fqs_loop rcu_gp_kthread → This indicates the kernel got stuck trying to grab a spinlock during RCU grace period cleanup. Why This HappensKernel/Driver Bug Most common cause. Since you’re on Unraid 7.1.4 (kernel 6.12.24), this could be a regression in RCU + ZFS or RCU + NVIDIA drivers. Both ZFS and GPU drivers are heavy users of locking. Resource Starvation If one CPU core is pegged at 100% (tight loop), the RCU threads can get starved and trigger this warning. Check if you had a VM, Plex, Tdarr, or GPU job maxing out CPU/GPU before the crash. Hardware Edge Case Bad RAM or unstable overclocking (if enabled) can cause locks to never resolve. How to Safely RestartSince your system is already throwing RCU stalls, it may not shut down cleanly. Do this: Try a graceful stop first (recommended): /usr/local/sbin/powerdown * This will attempt to stop the array, unmount disks, and kill processes. If that hangs for >2–3 minutes: sync reboot -f * `sync` flushes writes to disk. * `reboot -f` forces a reboot without waiting for hung threads. Next Steps After RestartCheck syslog (Tools → System Log) for warnings before the panic. Update: Make sure you’re on the latest BIOS for the ASRock Z690 Extreme. See if Unraid 7.1.5 (or newer kernel) is available — 6.12.24 has had reports of RCU-related hangs. Isolate: Temporarily disable ZFS or NVIDIA drivers to test stability. Run memtest from the Unraid boot menu. ⚠️ Bottom line: This wasn’t you doing anything wrong — this is most likely a kernel/module bug aggravated by ZFS or NVIDIA drivers under 6.12.24. Do you want me to build you a step-by-step recovery & isolation plan (BIOS update → memtest → driver isolation → kernel update) so you can nail down whether this is software or hardware? Fix common issuesShare appdata set to cache-only, but files / folders exist on the array [no idea how to fix] Share plex_cache set to cache-only, but files / folders exist on the array [no idea how to fix] The plugin folder.view.plg is not known to Community Applications and is possibly incompatible with your server [action plan to remove, which sucks it is GOLD] other actionsgoing to disable nVIDIA as well

I can not see the actual containers to add to the folder. All of the existing folders are in the same state, none of the existing containers are there, and can not add new ones.

problem when people do this is that the links change and there is no permanent answer.

Went to the config of the container and edited the IP to force a docker view docker run -d --name='ActualServer' --net='eth2.40' --ip='10.10.20.155' --pids-limit 2048 -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Zeus" -e HOST_CONTAINERNAME="ActualServer" -e 'TCP_PORT_5006'='5006' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:5006]' -l net.unraid.docker.icon='https://github.com/actualbudget/actual/raw/master/packages/desktop-electron/icons/icon.png' -v '/mnt/remotes/10.10.10.2_ActualBudget/':'/data':'rw' 'actualbudget/actual-server' 7d40c0fb3e922314ed6d887ccd12db4925af07d37ed21597888fd3aaf66fc9de docker: Error response from daemon: error while creating mount source path '/mnt/remotes/10.10.10.2_ActualBudget': mkdir /mnt/remotes/10.10.10.2_ActualBudget: file exists. The mount point is mounted in the MAIN Open console root@Zeus:/mnt/remotes# ls 10.10.10.2_ActualBudget /bin/ls: cannot access '10.10.10.2_ActualBudget': Stale file handle go to main page and unmount the share Feb 28 08:27:35 Zeus unassigned.devices: NFS mount failed: 'mount.nfs: access denied by server while mounting 10.10.10.2:/volume1/ActualBudget'. Feb 28 08:27:35 Zeus unassigned.devices: Remote Share '10.10.10.2:/volume1/ActualBudget' failed to mount. root@Zeus:/mnt/remotes# ls 10.10.10.2_ActualBudget /bin/ls: cannot access '10.10.10.2_ActualBudget': Stale file handle check the published drives root@Zeus:/mnt/remotes# showmount -e 10.10.10.2 Export list for 10.10.10.2: /volume1/ROM 10.10.0.0/16 /volume1/hoarder 10.10.0.0/16 /volume1/DVR 10.10.0.0/16 /volume1/AudioBooks_Indexed 10.10.0.0/16 /volume1/Paperless-ngx 10.10.0.0/16 /volume1/CD_Backup 10.10.0.0/16 /volume1/homes 10.10.0.0/16 /volume1/LightRoom Backup 10.10.0.0/16 /volume1/Plex-Music-m4a 10.10.0.0/16 /volume1/consolidation 10.10.0.0/16 /volume1/Zeus 10.10.0.0/16 /volume1/photoshare 10.10.0.0/16 /volume1/audiobooks-inbound 10.10.0.0/16 /volume1/Local-copyof-Brandon-Videos 10.10.0.0/16 /volume1/Docker_Configs 10.10.0.0/16 /volume1/Plex-AudioBooks 10.10.0.0/16 /volume1/Downloads 10.10.0.0/16 /volume1/Audible Book Storage 10.10.0.0/16 /volume1/Plex Videos 10.10.0.0/16 root@Zeus:/mnt/remotes# Go to the NAS - An encrypted share - Not mounted - needed to enter encryption key - share mounts Go to UnRAID - Mount remote share - Start Docker # working.

zeus-diagnostics-20250228-0813.zip Can not launch Container "Actual Server" no logs on system, no logs on app (that I can find) Click start, get error Hit ok, app does not start.

Problem fixed on Synology!!! Overview: NAS mounts failed after the plugin upgrade. Root determination was that one of the three Synology NAS would not respond to a > showmount -e {host} And the plugin was now requiring the response as a health check or something. Other NASs on network were responding. Resolution: On Synology Control Panel -> Networking -> General -> Advance Setting -> (uncheck) Reply to ARP request if the target IP address is Identical to a local address configured on the incoming interface. Turning this option off enabled unRAID to receive a response to the showmount command. Packet traces of the command showed Problem Troubleshooting 1. Portmap (rpcbind) Lookup The command starts by performing a portmap lookup to determine the port associated with the NFS mount daemon on 10.10.10.2. Packets 104–114: A connection is established on port 111 (typically used by the rpcbind service), and the client sends a V4 GETADDR call. The GETADDR response is received, and then both the client and server initiate a graceful close of the connection, which completes without errors. 2. Connection Attempt to NFS (Port 2049) After resolving the mount daemon’s port (likely 2049), the client tries to establish a connection directly to port 2049. Packets 284–296: The client and server successfully complete the TCP three-way handshake on port 2049, but soon after, the client sends only a single byte of data (Len=1). This could be a part of the showmount -e command query. Following the initial data, the client immediately sends a FIN to terminate the connection. The server responds with an ACK, but also sends a duplicate ACK (Packet 291), which may indicate either minor packet reordering or an unexpected early termination. Shortly afterward, the server sends a FIN and then a RST (Packets 292–293), suggesting the server is forcefully terminating the session. 3. Repeated Portmap Lookups Packets 297–306: The client repeats the connection to port 111 to perform another V4 GETADDR call, indicating that it’s attempting to re-establish the lookup for NFS service ports. This cycle of portmap lookups and brief connections to port 2049 continues (as seen with additional V4 GETADDR calls in Packets 322–326). The Synology NAS that was having the issue has multiple interfaces. Two interfaces are configured for the same subnet (only one active). From Synology's documentation https://kb.synology.com/en-ca/DSM/help/DSM/AdminCenter/connection_network_route?version=7 " if you have more than two network interfaces in the same LAN, enabling this option causes network flow on each interface to be transported separately. " The inactive interface is a built-in 1GE port, with the active interface an expansion card for 10GE This seems like a Synology BUG, as the second interface is disabled, but the packet reordering was causing the issue.

Thank You for all the support and great product. showmount works on every linux/unix host I have EXCEPT UNRAID..... Mac, Debian, Ubuntu, the issue is isolated to unRAID There is a 'delta' on one of the NAS as one works the other does not, but I can not see it in the config I did reduce both iPlex(unRAID) and NAS2(Synology) to a single TRUNK interface, turning off other NICs Like the idea of opening the ticket with Synology to see if they know why For now I hard coded the mounts into the GO file, and I am in service, but need to work why there is an issue with Synology.

TL;DR - I can CLI mount the nsf share, and UD sees it, but can not control it, but works. All other attempt to make this work is failing. if there is a binary on one of my working unRAID servers that I can copy over I will. At this time I will need to look at using fstab or whatever unraid uses to mount drives as the application is not working. I will also investigate the delta from NAS2 and NAS3, they are different CPU thus different code bases for DMS. <<update>> I added a bunch of mkdir, and mounts to the /boot/config/go file and the nfs are mounting without the plugin. Please advise if there is something I cna do to make this work, but I can not find anything wrong in the settings of the NAS, and every linux box I try can do the showmount -e except unRAID, and two unRAID boxes work with UD ---------------------------------- 1) Test NFS Mount capability: On iPlex(10.10.9.1) from Terminal root@iPlex:/mnt/remotes# cd /mnt/remotes/ root@iPlex:/mnt/remotes# mkdir temp root@iPlex:/mnt/remotes# mount -t nfs 10.10.10.2:/volume1/CD_Backup /mnt/remotes/temp/ root@iPlex:/mnt/remotes# ls temp #recycle/ CD\ Archive/ CD_Backup/ ISOs/ root@iPlex:/mnt/remotes# showmount -e 10.10.10.2 rpc mount export: RPC: Unable to receive; errno = No route to host root@iPlex:/mnt/remotes# mount rootfs on / type rootfs (rw,size=65351992k,nr_inodes=16337998,inode64) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) <<<snip>>> nsfs on /run/docker/netns/f39e45745080 type nsfs (rw) nsfs on /run/docker/netns/6393cf2a7dcf type nsfs (rw) 10.10.10.2:/volume1/CD_Backup on /mnt/remotes/temp type nfs (rw,noatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.10.2,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=10.10.10.2) Results: There is something with NAS2 preventing unRAID to do a 'showmount'. This is consistent across all three unRAID servers. The unRAID server can mount the NFS Share even though the showmount can not see the exports Conclusion: The 'showmount' issue is not with NAS3, only NAS2, but not core to inability to mount NFS shares 2) Uninstall and reinstall (attempt 1) Shutdown the array Removed unbalance plugin(s) via gui Reboot the server Install the **Unassigned Devices** Same condition Checked /boot/config/plugins-error it is empty Checked /boot/config/plugins-removed and noticed it keeps a copy of removed plugins. If I had a corrupt file the plugin may not be re-downloaded. Checked /boot/config/plugins/unassigned.devices and see 4 files -rw------- 1 root root 1 Apr 14 2024 iso_mount.cfg -rw------- 1 root root 1600 Oct 30 19:24 samba_mount.cfg -rw------- 1 root root 132126 Oct 31 10:23 unassigned.devices-2024.10.29a.tgz -rw------- 1 root root 1079 Oct 31 10:23 unassigned.devices.cfg It appears that the samba_mount.cfg holds all the samba and nfs configs I add an nfs mount via gui, it failed with the mount grey'd out, this is added to samba_mount.cfg From samba_mount.cfg [10.10.10.2:/volume1/CD_Backup] protocol="NFS" ip="10.10.10.2" path="/volume1/CD_Backup" share="CD_Backup" With this configuration in place I execute mkdir /mnt/remotes/10.10.10.2_CD_Backup mount -t nfs 10.10.10.2:/volume1/CD_Backup /mnt/remotes/10.10.10.2_CD_Backup The dashboard changes to an odd state. The line for CD_backup Unmount turns from grey "Mount" to orange "UNMOUNT" the USED and FREE having bar graphs showing 0B Orb best the NFS is showing grey not green The link to the share is back not blue and not a hyperlink Pressing the UNMOUNT, turns it Grey again, but DOES NOT unmount the share, and does not return to Orange. 3) Uninstall and reinstall (attempt 2) GUI, click uninstall root@iPlex:/boot/config/plugins-removed# rm unassigned.devices.plg Unassigned devices is no longer showing as previous installed apps Install via App Store SAME CONDITION The install read the /boot/config/plugins/unassigned.devices/samba_mount.cfg and remounted all the smb and the nfs to NAS3 4) Uninstall and reinstall (attempt 3) GUI, click uninstall root@iPlex:/boot/config/plugins# rm unassigned.devices/ -R root@iPlex:/boot/config/plugins-removed# rm unassigned.devices.plg Install via App Store As expected no shares exist for SMB or NFS Add a nfs mount to 10.10.10.2:/volume1/CD_Backup Mount button is greyed out.

I understand that the above is a standard help file, and Thank You for all the help. I just line by line screen by screen the two NAS's are set the exact same. NFSv2.NFSv3 Firewall disabled There is a delta between NAS2 and NAS3 and I will do a wireshark trace tomorrow to see what is happening. Another data point on Zeus(10.10.20.1) a unRAID Server NAS2 is mounted on Dockofthebay(10.10.15.1) a unRAID Server NAS2 is mounted root@Zeus:~# mount rootfs on / type rootfs (rw,size=32944356k,nr_inodes=8236089,inode64) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) <<<SNIP>>> nsfs on /run/docker/netns/83fc2e3fc9fc type nsfs (rw) nsfs on /run/docker/netns/160e67d0ecd3 type nsfs (rw) 10.10.10.2:/volume1/AudioBooks_Indexed on /mnt/remotes/10.10.10.2_AudioBooks_Indexed type nfs (rw,noatime,vers=3,rsize=131072,wsize=131072,namlen=255,soft,proto=tcp,timeo=300,retrans=4,sec=sys,mountaddr=10.10.10.2,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=10.10.10.2) the mount is working fine, I can see and use the files. but showmount is failing root@Zeus:~# showmount -e 10.10.10.2 rpc mount export: RPC: Unable to receive; errno = No route to host root@Zeus:~# once again, the showmount will work on 2 different Macs on the subnet. All my googling leads to a firewall issue, but there is no firewall, it is a single subnet with the same VLAN. Thank You for looking at it. In a Nut Shell NAS2 is exporting NFS Mounts the Mounts can be mounted by two Macs, and two unRAID Servers, but not a third unRAID server No UnRAID Server can do a showmount to NAS2, but can to NAS3. Macs can do a showmount to NAS2, and report that the NFS share is shared and to the whole subnet. The mounts to iPlex(10.10.9.1) worked yesterday, something happed on the unRAID server, as I did not touch the NAS. will look at wireshark in the morning.

I do not think so? - All hosts UnRAID and Synology are in 10.10.0.0/16 subnet - iPlex with the issue is 10.10.9.1 - Zeus (unraid server) is 10.10.20.1 - NAS2 (with the issue to iPlex) is 10.10.10.2 - NAS3 is 10.10.10.3 Zeus can mount from NAS 2 & 3 iPlex Could until 1 day ago mount from NAS 2 & 3, but now only 3 The showmount -e shows that the subnet is permitted when executed from another host no firewall on NAS2 "What changed 1 day ago" - I had a POOL with two drives, and one drive failed. It was messy getting everything off of the pool to array, but I think I got it all. APPDATA was on the pool, but the OS can not find an NSF mount route to the NAS? IF there is something you think based on all this that the NAS is configured wrong, let me know. As all other hosts on the subnet can mount to from it, and SMB works for iPLEX just no NFS.

NFS on unRAID is starting to bug me..... I found the bug that if you stop and start the array, NFS stops working. Now, I have two remote hosts, both are synology, that share their directories via NFS. One will mount, one will not. After a clean reboot > rpc mount export: RPC: Unable to receive; errno = No route to host removing the NFS mount, and adding an SMB to the same share, I can mount it. tests; root@iPlex:~# ping 10.10.10.2 PING 10.10.10.2 (10.10.10.2) 56(84) bytes of data. 64 bytes from 10.10.10.2: icmp_seq=1 ttl=64 time=0.338 ms 64 bytes from 10.10.10.2: icmp_seq=2 ttl=64 time=0.174 ms ^C --- 10.10.10.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1031ms rtt min/avg/max/mdev = 0.174/0.256/0.338/0.082 ms root@iPlex:~# showmount -e 10.10.10.2 rpc mount export: RPC: Unable to receive; errno = No route to host root@iPlex:~# showmount -e 10.10.10.3 Export list for 10.10.10.3: /volume1/VinylStudio 10.10.0.0/16,10.99.99.0/24 /volume1/Drobo-8D 10.10.0.0/16 /volume1/Nikon 10.10.0.0/16 /volume1/Apple-Music 10.10.0.0/16 root@iPlex:~# from a different host on the network > showmount -e 10.10.10.2 Exports list on 10.10.10.2: /volume1/nextcloud 10.10.0.0/16 /volume1/homes 10.10.0.0/16 /volume1/LightRoom Backup 10.10.0.0/16 /volume1/Plex-Music-m4a 10.10.0.0/16 /volume1/consolidation 10.10.0.0/16 /volume1/Zeus 10.10.0.0/16 /volume1/photoshare 10.10.0.0/16 /volume1/AudioBooks_Indexed 10.10.0.0/16 /volume1/CD_Backup 10.10.0.0/16 /volume1/audiobooks-inbound 10.10.0.0/16 /volume1/Local-copyof-Brandon-Videos 10.10.0.0/16 /volume1/Docker_Configs 10.10.0.0/16 /volume1/Plex-AudioBooks 10.10.0.0/16 /volume1/Plex Videos 10.10.0.0/16 /volume1/Downloads 10.10.9.1 10.10.10.5 > showmount -e 10.10.10.3 Exports list on 10.10.10.3: /volume1/VinylStudio 10.10.0.0/16 10.99.99.0/24 /volume1/Drobo-8D 10.10.0.0/16 /volume1/Nikon 10.10.0.0/16 /volume1/Apple-Music 10.10.0.0/16 Both Hosts are Synology No firewall unraid can ping synology synology can ping unraid

Is there a Restore guide? I think all is going well with this excellent app. If I need to restore, is there a procedure for that? Seems straightforward in the restore tab, but before I panic because of a colossal failure and scrambling to get things back, I love to read the how-to.

Good Morning - love the idea, failing for me. First is the password in the config file, I really do not like having clear passwords in config files. - I tried removing the line and then sudo pihole -a -p to add one, this worked until I restarted the container, and it fails back to nothing Second the configuration is not persistent - I set to resolve to OpenDNS and not use it's self as that does not work, and it starts to work. I reboot and I am back to the original config. Probably not understanding how this is to work (I do run PiHole on a Pi for 5 years) but I will need to switch to another container as this one does not pass security or restoration tests. let me know if I am missing anything.

Thank You I think I may be out of the woods. 1) Bad SSD devices causing cache issues to shares using it, including APPDATA, PLEXVIDEO 2) MACVLAN on BR been an hour with zero logs. If I have more issues I will start another thread to keep a multi layer problem clear. Thank You for the help.

MACVLAN is important to my Security profile, as each Container has a specific IP and MAC that can be identified by Firewall, IDS and IPS. This is very very unfortunate, and if I can not find a work around, may require me moving from unRAID. MACVLAN is a core function of Dockers.

Using Plex unraid high CPU on cores, that never change No dockers shown on the dash board Can not view dockers (took over 1 minute) Waited, and partial list Please help