chris1259

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

"The client noticed that the server is not Elasticsearch and we do not support this unknown product" This is the same issue i had when i tested both elasticsearch dockers available in community applications for v6.6.2 and v7.10.2 at the time. Does this message have anything to do with licensing / forking the project? I installed Elasticsearch 8, as suggested by JAnguita, from the repository "docker.elastic.co/elasticsearch/elasticsearch:8.11.1", but it did not help. Additionally: On v8.11.1, running "/usr/share/elasticsearch/bin/elasticsearch-plugin install --batch ingest-attachment" no longer works and provides the message: "[ingest-attachment] is no longer a plugin but instead a module packaged with this distribution of Elasticsearch -> Please restart Elasticsearch to activate any plugins installed" I don't see occ installed, and do not know the name of the module.