metalchad

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?