chris1259

Two of my three servers upgraded to 7.3.3 without issue. Those two either had no additional GPU or an NVIDIA RTX 3060. The third server booted back into the OS, but only one of its three network connections appeared in the GUI, so it appeared offline. The upgrade also pulled in the newest NVIDIA driver, which doesn’t support the older GPUs in the 3rd server and broke Plex. I rolled back to 7.3.2 to fix the networking, then had to repair the NVIDIA driver by hand. I should also mention that every few versions, an OS update changes the settings under Settings > Network Settings > Interface Rules. When that happens, I have to correct them before the server has network access again. echo "== BOARD =="; dmidecode -s baseboard-manufacturer; dmidecode -s baseboard-product-name echo "== NICs =="; lspci | grep -i -E "ethernet|network" echo "== GPUs =="; lspci | grep -i -E "vga|3d|display" BOARD ASRock X99 Extreme4 (Released August 2014) NICs 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V (rev 05) 01:00.0 Ethernet controller: QLogic Corp. cLOM8214 1/10GbE Controller (rev 54) 01:00.1 Ethernet controller: QLogic Corp. cLOM8214 1/10GbE Controller (rev 54) GPUs 02:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1) 03:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1) Plex issue: Plex wouldn’t start because Docker failed at container creation, before Plex ever ran. The container was configured to use the NVIDIA runtime, and the host’s NVIDIA driver wasn’t working. That was a side effect of the Unraid 7.3.2 → 7.3.3 upgrade and rollback: The Nvidia Driver plugin ended up with driver 615.78.08, which is too new for my cards. The GTX 960 (Maxwell) and GTX 1060 (Pascal) are only supported through the 580 branch, so nvidia-smi couldn’t talk to either GPU. When I switched to 580.173.02, the 580 package never made it to the flash drive. Only the stale 615 package was cached, so after the reboot the kernel module was 580 but the userspace tools were 615. That mismatch caused the NVRM “API mismatch” errors and kept the container runtime from working. Plex Fix: Deleted the stale 615.78.08 package folder from /boot/config/plugins/nvidia-driver/packages/. Re-downloaded 580.173.02 through Settings → Nvidia Driver, and verified the .txz and .md5 files landed on the flash drive before rebooting. Rebooted. nvidia-smi now reports driver 580.173.02 and lists both GPUs, and Plex starts.

This resolved my issue with my Nvida 960 and 1060 for Plex and tdarr. Downgrade to driver v580.

Downgrading to v580 resolved my issue on Plex and tdarr dockers with my 960 and 1060. Thank you!

This resolved my issue with my Nvida 960 and 1060 for Plex. Downgrade to driver v580.

3 Servers upgraded without issue from 7.1.4 to 7.2 with no data loss like last time.

A report was submitted for this under Stable Releases, and my mistake about posting this in the wrong forum. It wasn't my intention to create such a big post.

A report was submitted for this under Stable Releases.

Thank you for your input on this. For the HDDs on T04, that would mean 4 different HDDs with 1-2 years of usage max all failed. The drives themselves are fine and were only corrupted during the upgrade. I was able to replicate this issue. The the GPU on T02 is a Nvidia EVGA Geforce GTX 960 SuperClocked Gaming with drivers v575.51.02. Next time i attempt to upgrade i will downgrade the drivers. Thanks!

This is a continuation of my original thread of all issues i have experienced after upgrading to v7.1.0 and v7.1.2. The last stable release for me was v7.0.1, which i have reverted to on one of the 2 servers. The newest issues are as follows: Server T02 (Now running v7.0.1 - was upgraded to both 7.1.0 and v7.1.2) Crashed before reboot after upgrading to v7.1.2 from v7.0.1. Plex docker will no longer accept the extra parameter --runtime=nvidia; nvidia drivers are installed and working. This also affected the GPU Statistics plugin v2025.04.27. The webgui is no longer available within 2 days. Webgui feels slower than normal. SMB no longer works within 2 days. Docker was still working and had network access! No video out when hooked up to a monitor. Momentary press of the power button for a soft shutdown did not work; had to hard reset. NO flash appeared on the webgui. I am preparing a second USB to test with incase this is all related to an aging USB drive. Server T04 (Now running v7.1.2; upgraded from 7.0.1) 2 HDDs again corrupted with the message Unmountable: wrong or no file system (different HDDs each time). Same issue when upgrading to v7.1.0 from v7.0.1. Running Check Filesystem or Disks (gnome-disks) on Ubuntu did not fix the issue. I did not run any other data retrieval software to try to salvage the data as this is a backup server. My first post has the messages displayed when trying these 2 utilities. Random reboot after parity check completed. Webgui feels slower than normal. Webgui can no longer show the disks in the array on the Dashboard or Main tab. Downloading diagnostics data never completes; i let it sit over an hour. None of these issues are present on v7.0.1. At this time i am not asking for assistance and only wanted to share my experience. UPDATE 1: I found another reproducible issue on T04 where after using the Terminal in the upper right hand corner of the webgui and exiting, the webgui no longer shows the drives (no longer visible but array is online) in the array for about 30 mins, then it returns. Clicking refresh does not work. The drives are also no longer visible from Main > Array Devices. This same issue also occurres when trying to move files under Shares > [Pick a share] > move files. The files i was trying to move were 12.2TB in size amounting to just over 10,000 files. I let it sit for over an hour and no files were moved. I have only been able to move small files or small amounts of files with this built in feature in the past. I ended up using the docker Krusader and moved the files in a few seconds since they were all on the same server (T04). While i was updating this post T04 randomly rebooted and i was able to retrieve diagnostics (T04-diagnostics-20250513-1540.zip) this time. When the reboot happened a Windows 10 22H2 VM was running and performing a large file sync with robocopy. This was working fine for several hours before the server rebooted unexpectedly. After the reboot i reverted from v7.1.2 to v7.0.1 and again 2 drives were showing Unmountable: wrong or no file system and had to be reformatted. Downloading diagnostic data is not working on T04 after downgrading to v7.0.1, and the drives in the array are not visable, but the array is online. Diagnostics (T02-diagnostics-20250512_1030.zip) from T02 was collected while it was still running v7.1.2 at some point. A report was submitted for this under Stable Releases. T02-diagnostics-20250512_1030.zip T04-diagnostics-20250513-1540.zip

Upgraded from 7.0.1 to 7.1.0 on 2 machines: 1st machine (T02) was fine, 2nd machine (T04) was fine except for the Windows 10 VM with 2 virtual disks on 2 different drives disappeared. Downgraded to 7.0.1 and it did not fix the issue. Upgraded again to 7.1.0 and the VM did not return. Under Settings > Backup/Restore Appdata > Backup VM meta is set to yes, and Settings > VM Manager > Enable VMs is set to Yes. Some posts state the XML is within /mnt/user/system/libvirt/libvirt.img which i do have a backup of before the upgrade. Is there another location where the XML file can be found? UPDATE: 2 of my non-parity drives are now reporting as "Unmountable: wrong or no file system" on T04, yet there are no errors and the array is mounted. I am attempting to put the array in Maintenance mode and run a filesystem check. UPDATE 2: While waiting for the filesystem check to run i found the VM XML in my backup CommunityApplicationsAppdataBackup > DATE_OF_BACKUP > vm_meta.tgz > vm_meta.tar > etc> libvirt > qemu. UPDATE 3: Clicking on the disk and pressing the Check Filesystem Status button on T04 was unsuccessful after running for more than 11 hours. Both HDDs are reporting the same message over and over: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock unable to verify superblock, continuing... I also attempted fixing the filesystem with Disks (gnome-disks) on Ubuntu and it failed right away with the final message "Corrupt index block signature", "Failed to open $Secure: No such file or directory" and "Remount failed: No such file or directory". I ended up reformatting the drives in unRaid. Restoring the VM went a lot smoother: Virtual Machines > Add VM > create a generic VM but do not start it > enable form view > paste in XML and start it. A report was submitted for this under Stable Releases. T04-diagnostics-20250513-1540.zip T02-diagnostics-20250512_1030.zip

Using unRaid v7.0.0-beta3 I have not fixed it and tried again today with the following results: Opened the console to the Nextcloud Docker version Hub 9 (30.0.0), change directory to /var/www/html/ and ran the command ./occ fulltextsearch:test. Elasticsearch Docker 6.6.2 $ ./occ fulltextsearch:test .Testing your current setup: Creating mocked content provider. ok Testing mocked provider: get indexable documents. (2 items) ok Loading search platform. (Elasticsearch) ok Testing search platform. fail In SimpleNodePool.php line 68: No alive nodes. All the 1 nodes seem to be down. Elasticsearch Docker 8.11.1 $ ./occ fulltextsearch:test .Testing your current setup: Creating mocked content provider. ok Testing mocked provider: get indexable documents. (2 items) ok Loading search platform. (Elasticsearch) ok Testing search platform. fail In CurlFactory.php line 146: cURL error 60: SSL certificate problem: self-signed certificate in certificate chain (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://SERVER_ADDRESS:9200/ I also tried the Let's Encrypt certificate URL provided by unRaid as the address entered in Nextcloud under Administration / Full Text Search / Address of the Servlet.

Thank you for the explanation. Thus far, all the drives i have replaced have either failed or gone offline (disabled). In each case, i replaced the disk with a new one and rebuild did the rest. Next time i will place the array in maintenance mode, and review what repair options are available.

I formatted the unmountable disk outside of the server to confirm no bad sectors were found. I did not return this newly formatted disk to the array. From the link you provided, it sounds like the file system had become corrupted, and i may have been able to fix it. What is unclear to me is the difference between an unmoutable corrupted drive, and a drive that is no longer working. Why does the data rebuild work on a dead drive, but not a drive that was replaced because it was unmountable. Thanks.

unRaid v6.12.9 9 X 12TB Seagate Exos X14 Drives 2 of the drives are parity drives. After upgrading to v6.12.9 from 6.12.8 and rebooting, the server automatically started a parity check. I let it run and it found 11733 errors. After another reboot one of the data disks reported as unmountable. I replaced the drive and the rebuild started; however, i noticed my main network share that was 84% full, now only reported 70% full. The data rebuild finished successfully with zero errors after i replaced the disk. The unmountable disk was tested outside of the server and had no issues, including a full format. Since 2016, i have replaced bad disks before and never lost data. All important data was backed up on other devices, and i should be able to restore most of what i lost from there. I am now trying to understand what happened. Any help is appreciated! diagnostics-20240401-1203.zip