metalchad

Booted onto a live disk of system rescue 13 and ran dosfsck -l -v -a -t /dev/sdi1 rebooted and my ssd showed up for my cache pool. Running a parity check. I'm able to add/edit/order docker containers, settings are saving, etc. So all appears okay for now. I'll continue monitoring.

Stopping the array from the "STOP" button didn't stop the array, so I selected "REBOOT" which lead to an unclean shutdown of the array. I have attached a diagnostics from before starting the array after reboot and another after I started the array. It appears one of my SSD's in my cache pool no longer exists 😢 The monitor.ini is readable again. Parity check is running. Let me know if anything about the diagnostics requires attention. mimir-diagnostics-20260407-1544.zip mimir-diagnostics-20260407-1548.zip

@JorgeB I still have not rebooted because I am unable to disable VMs or Docker, which I would like to be able to do before stopping the array and restarting. I was able to stop all running containers and VMs. @itimpi I am unable to delete or mv the file "Read-only file system". Updating anything in Setting->Display do not save. I suppose the only thing to do is attempt to stop the array and reboot and provide another diagnostics after starting the array back up.

Alright, not sure why it took me this long to notice, but for a few months I've been shown the error in the title of this post on my fix-common-problems report. I found that the backup of my flash from the day before it started does not have the corrupt file - not sure if other files are corrupt on the previous backups and I don't know if the error began happening due to some action somewhere else 🤷‍♂️ In any case, there appears to be a few more errors in the logs potentially with my btrfs mirrored ssd cache-pool, which is not really used for anything at the moment but I have been looking to update to move my boot from a USB thumb drive to the SSD. I only noticed this error because I noticed that reordering my docker images didn't seem to stick, and one of my docker containers could not be upgraded. I would like to think I could just find a thumb drive and restore a non-corrupted backup to it and be on my way, but my concern is that the backup may be too far out of date for any recent changes I may have made, which shouldn't include any array configurations. Anyway, just looking for someone to analyze my diagnostics and advise me on what my next steps ought to be. Should I just overwrite the monitor.ini with an uncorrupted version, and perform a reboot, or is there more to consider? mimir-diagnostics-20260405-2243.zip

Were you able to find a resolution to your issue with your MariaDB containers? I'm experiencing the same issue on 6.11.5 but was not previously upgraded to 6.12.1 UMASK must be a 3-digit mode with an additional leading 0 to indicate octal. The first digit will be corrected to 6, the others may be 0, 2, 4, or 6. UMASK corrected from 022 to 0640 ... 230707 14:09:14 mysqld_safe Logging to '/config/databases/608d93154c87.err'. 230707 14:09:14 mysqld_safe Starting mariadbd daemon with databases from /config/databases Caught SIGTERM signal! cat: /var/run/mysqld/mysqld.pid: No such file or directory EDIT: Looking into the referenced log I found [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.5.12. You must start up and shut down MariaDB 10.7 or earlier. So, I changed the tag in the repository field to :10.5.12 Chances are you have a similar log entry

Rebuild of both parity and data drive completed successfully. Haven't yet verified my files are not corrupt, but they seem to be there; good enough for me to mark this as solved. Thanks @trurl

Ah, that makes sense. Thanks for the link. I'll provide an update when there is one to report.

Seems odd though, that only 2 of the drives dropped, and not all 5, as they are all in the same 8 bay enclosure.. really wishing I had that syslog. Anyway, I'm not entirely sure what the exact procedure is to re-enable the drives and start the the rebuild. Any chance you could point me in the right direction?

I'll start this off by saying that unfortunately this happened on a day that I did not have the bandwidth to deal with the issue. Being a novice to unRAID, I did not get the syslog before stopping the array and shutting down thinking, "I'll deal with this when I get back". Really wish I'd have gotten that syslog... (feature request: email syslog when array errors are encountered, perhaps a plugin or user script already exists that I'm not aware of?) I'm basically looking for the next steps I should take to attempt to recover here. Sequence of events according to email notification I have set up: [02:01] unRAID started the parity check [11:09] unRAID parity disk error [11:09] unRAID disk 1 error [11:09] unRAID Array has errors [13:17] Parity check cancelled (this was my doing, I believe it suspended itself and I cancelled before stopping the array then shutting down) From all that I've read, I believe that an issue with the controller (within an enclosure) caused the drive to drop unexpectedly. But I may have a unique set-up here, open to critiques. ASROCK Z490M PRO4 Intel I9-10850K EVGA GeForce RTX 3080 FTW G.SKILL 32GB 2X16 D4 3200 RIPJAWS (non-ECC) 2x 480GB SanDisk SSD - SATA 1x 1TB NVMe - PCIe 5x 4TB HDD - USB 3.2 in a Mediasonic Probox enclosure Perhaps I'm a bit paranoid, as I understand nobody should need dual parity for the amount of disks I'm using, be that as it may, I set it up with dual parity. But, hopefully that saves me because it would seem that the rarest of cases happened with 2 drives failing at the same time. I'm not storing the planet on my rig. I run a few dockers including Plex and have a Windows 10 VM dedicated to gaming. And then of course I store personal files, photos/gopro videos, etc., and have had the intention to set up Backblaze for offsite backup of those, but am not quite there yet. At the time of the failure, I don't believe there was any disk activity other than the reads from the parity check happening. In all my searching I haven't found another post or article that explains how to rebuild from the state I am currently in, which is that Parity disk 1 and array disk 1 are both in disabled states. Please advise. Diagnostics attached. Thanks in advance. mimir-diagnostics-20210908-2135.zip

I'm not sure what you've set the value of 'Output Dir' to in the setting for the docker container, but in my case it is set to a user share and I don't believe I had to set any permissions on the share, but in your case it looks like you may be lacking some permissions for it to be able to write data; see the error in your output above chown: cannot access '/out/CD': No such file or directory If your output directory is a valid user share and you see the Ripper/CD folder in it, perhaps doing a chmod +rwx on the folder from the terminal will solve your problem. Sorry, I misread initially.. You shouldn't have to create the CD folder yourself, I don't think, perhaps the Ripper folder I did have to create myself on my user share, cannot recall - but the ripper script should take care of creating CD/Bluray/DVD/etc.. folders, if it doesn't then I have to believe there is a permissions issue.

Yes, it works out of the box for me. Once the docker is set up it will output your files to whatever you set your output directory to [output-directory]/Ripper/CD Each time a disk is inserted into the designated drive, in my case /dev/sr0, it will execute the ripper.sh script in your designated config directory, you can make your own CDrip.sh for full customization, otherwise it will create both FLAC and MP3 files using abcde.

Well, it does seem to be applied there as well, not sure if it was previously, my guess is no. Perhaps ~/.MakeMKV/settings.conf is set up as an alias of /ripper/settings.conf? And yes, I have successfully ripped a couple DVDs now since making the change. HOWEVER, and I'm sorry for this, I neglected to mention another change I did prior to the changes mentioned. Thinking that it was somehow getting a cached version of the docker image I decided to change the Repository field to rix1337/docker-ripper:1.16.4 to force it to get the 1.16.4 tag instead of latest and then did a force update of the container. This could have also contributed to the fix. After doing so I had to manually delete the 'latest' image version by running docker image remove rix1337/docker-ripper:latest

@rix @Guillaurent I seem to have resolved my issue, it seems the docker isn't bringing in the settings.conf as expected, thus the key not being used. I ran some commands on the container to check the contents of settings.conf files I had found there. docker exec Ripper cat /ripper/settings.conf The output showed an empty key string, then doing docker exec Ripper cat /config/settings.conf Showed my key. The /config is what is mapped to /mnt/user/appdata/ripper After simply overwriting the /ripper/settings.conf with /config/settings.conf manually, it worked. So either MakeMKV within the docker is looking at the wrong location or the mechanism for copying the values from the config/settings.conf to the ripper/settings.conf within the docker is at fault.

@rix I am having the same issue as @Guillaurent above. I have a valid MakeMKV key entered in the settings.conf and the latest docker image and am still receiving the "application is too old" message from MakeMKV. Is this an issue with MakeMKV checking the keys validity, or with the mechanism that supplies the key to MakeMKV?