AnnHashaway

I'll give you a Buffalo Nickel if you can remember anything that pointed you in the right direction. This is the EXACT issue I have been having for two months. Extracting ...PHP Warning: require(/config/www/nextcloud/updater/../version.php): failed to open stream: No such file or directory in phar:///config/www/nextcloud/updater/updater.phar/lib/Updater.php on line 658 PHP Fatal error: require(): Failed opening required '/config/www/nextcloud/updater/../version.php' (include_path='.:/usr/share/php7') in phar:///config/www/nextcloud/updater/updater.phar/lib/Updater.php on line 658 Round, and round, and round I go...

Great, thank you.

Is there a clean way to schedule auto-restarts for specific docker containers? I have been battling with Nextcloud and MariaDB for over a year now, and I haven't been able to find an effective solution to maintaining its performance speed consistently. The only method that works is restarting MariaDB, which brings the speed back to usable. Until I find the issue, I would like to simply have the docker container restart a few times a day so Nextcloud will continue to work when I'm away from the server. Any easy way to do this?

Attached

Attached denali-diagnostics-20210808-0831.zip

I am almost 1% in the rebuild at the writes to the parity are zero. EDIT: Should I zero out the drive with unassigned devices and try again?

I have been using this parity disk for a few years now. I have had a few power outage incidents with some data loss, but was able to use offsite backups to restore the data. I wonder if something happened at that point and I didn't notice. Is there a way to re-initiate it like a new parity drive and have it build the parity from scratch? Everything important is backed up locally and remotely, so I'm not worried about taking a swing. Thanks for you help.

I ran a diagnostics immediately after, just in case. Attached. denali-diagnostics-20210805-1610.zip

The last two times I have run a parity check, there are no reads or writes on the parity drive and it ends with over a billion errors. Unraid still says the Parity is valid. Whats the best way to start diagnosing this?

Ran xfs_repair -v on disk2, rebooted, and formatted disk3 again. Diagnostics attached denali-diagnostics-20190909-1651.zip

Here is a fresh set after another format attempt. This is done straight from the array while mounted. It only takes about 20 seconds to complete, and returns to the same Unmountable message. denali-diagnostics-20190909-1448.zip

Restarted the system. Same result. Diagnostics attached. denali-diagnostics-20190908-1610.zip

Attached. Thanks. denali-diagnostics-20190907-1548.zip

OK, I was able to format without taking it out of the array. It only took a few seconds, and I am getting the same readout of Unmountable. Are these the diagnostics I should post?

The Parity Sync / Data Rebuild process has finished, and the disk remains unmountable. (Attached) I am now going to move the drive to UA and run format.

The empty file system is ok. I can restore. The issue is I have run format on it probably 10 times. It fails to format each time in Unassigned Devices.

It is currently 5% through the Parity Sync / Data Rebuild process. Should I wait that out, or go ahead and add it back to unassigned devices and format?

I have an 8TB red parity and three 4TB red data drives. I took the server apart because I was going to change some parts, but ended up putting it all back together the same way. Once I booted back up, I am getting this message on one of the drives: Unmountable: Unsupported partition layout I have everything backed up, so I have tried to format the drive, preclear it, everything I could find for the last few weeks on the forums. No matter what happens, it comes back to this. When I preclear, the preclear fails after a day or so. (I attached the latest preclear report.) The only thing I haven't done is pull the drive and format it in another computer. I am not sure if that would work. Any ideas? Are there any other reports I can add here to help? Thank you. preclear_disk_WD-WCC7K0KE9C88_2123.txt

No, I hadn't seen that before. That could be what I'm looking for. Thanks for sending it over.

This one:

I am familiar with that, but was thinking these specified shares in the VM config would provide a better experience (e.g. like a mounted drive). I have limited space on the cache drive for the VM, and run into issues when trying to write large files (>10GB) directly to a network share via smb. So this option in the config doesn't really do anything?

I have a new VM set up running the latest Ubuntu Desktop 16.04. I have an Unraid share in the settings with /mnt/user/Storage/. The corresponding Unraid Mount tag is set to Storage. I see nothing inside the VM. Nothing in Media or /mnt. How do I get it to mount?

Did you ever find a solution to this? I am having a similar issue. I have an extra SSD that is mounted and accessible via Unassigned Devices. I can access from external machines and write to it just fine. However, when I map that drive to a docker app (like Deluge) the app cannot write to the drive, and I get a permissions warning. It appears that either Docker or the app itself has a different user permission setting, but I can't find how to change it. Anyone have an idea?

OK, so I had some tidying up to do in order to put the main work on the cache drive. 1. I had to manually move the appdata folder from each disk, directly to /mnt/cache/appdata and set the appdata share to Cache:Only. Used command line: cp -r /mnt/diskX/appdata/* /mnt/cache/appdata/ 2. Turn off each docker and turn them on one-by-one, while resetting the Main page stats so I could see which dockers were accessing the data drives consistently. This resulted in zero writes happening to the data drives, but I was still getting a few errant reads that kept a few of the drives up. It turns out that the apps Deluge and Sonarr were the culprits. Deluge is going to access a data drive any time it is uploading to someone else. Sonarr is a bit trickier, but basically, it is constantly checking the selected shared folder where your download programs would drop a file that was ready to be moved/renamed. I have an additional SSD plugged in and sitting idle. Its mounted via the Unassigned Devices plugin, and I think I can basically make part of it a seedbox, so Deluge will only pull data from that and keep the data drives from spinning up. I haven't worked through a solution for Sonarr yet, and it seems to access the shared folder every minute or two, so it keeps whichever drive Unraid is using for it up all the time. I think I may be able to create a new share that only lives on the cache, and make that the shared folder for Sonarr and the download programs. Any other ideas for this? I'll report back with my results.

Ha! I love how we often get so focused on the technical solution, that we can overlook the basics. Testing... will return with results.