itimpi

What makes you think the emulated disk is not being mounted? Both your screenshot and the earlier diagnostics show it mounted with about 12% of it containing data. The whole point of Unraid’s emulation feature is to allow the system to operate as though a failed/missing disk is actually present.

The parity disk(s) are optional in the array depending on if you want protection against disks failing., but you must have data disk(s).

The ‘little blue box’ is standard. You click on it to initiate File Manager. The NTFS question still applies - it is the file system you have set for the emulated disk1. Parity drives have no file system. Not sure what you did originally but disk1 is still being emulated so needs rebuilding to make it active again.. However since it is in NTFS format ideally you would copy it s contents elsewhere before rebuilding disk1 and copy the data back afterwards once it is formatted to a Linux style file system (probably want Xfs). Not sure why you have 2 parity drives protecting a single data drive. You may be better off using one of them as an additional data drive instead.

The system gets very confused if you have folders on the drives with the same name but different capitalization. Make sue that any paths in docker volume mapping are as you want them to end up, It would be easiest to Unraid's built-in File Manager to move files to the correct location. I would recommend that any docker containers that might use these paths are stopped while doing this. After that check the /boot/config/shares folder and check if there is a .cfg file with the capitalization that corresponds to the actual share folders on the drives. That system uses FAT32 so you cannot simply rename one to the correct capitalisation in a single step. If there is one with the wrong capitalization then remove it and return to the shares tab and make sure the settings for that share are as you want them. When you hit 'Apply' a new .cfg file will be created with the correct capitalization.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information. If anyone spots anything and comes to a conclusion you can then ask where they spotted the information that lead them to a suggestion if you want to think about doing this for yourself in the future.

The Licencing scheme allows for free upgrades within the given point release even if not eligible for upgrades to a later point release. Since you are 6.12.10 you should be able to upgrade for free to 6.12.15 which is the last release within the 6.12 versions of Unraid.

In terms of checking config files (*.cfg) it is worth mentioning that they should all be human readable text files so opening them in a text editor tends to make it obvious when corruption has occurred.

Normally I would suspect something like a too restrictive Split Level causing this type of issue or perhaps the include/exclude on the share settings but it does not look like this is the issue looking at the share .cfg files in the diagnostics you supplied. It might be worth checking that you do not have a job explicitly writing to disk4. The most likely candidate is whatever is writing to the B----------s share as this only exists on disk4.

Yes. You can also delete the preclear_reports folder. Not sure what that Android folder is? Maybe it is not needed either.

Looks like a lot of corruption was detected. You only ran the check according to the attached log - you did not appear to have run a correction? Not having one is a good sign. However that check is one to make AFTER running a xfs_repair in ‘fix’ mode.

Maybe, but the update said it had finished in the progress window.

when I updated plugins after installing this release I now get a "Dismiss" button instead of a "Done" button after the plugin update completes. I found this confusing ☹️

4GB should be enough to be able to upgrade via the GUI, although occasional housekeeping to get rid of extra files might be necessary. You can always delete the contents of the Logs folder before trying to upgrade via the GUI. If necessary you can also delete the Previous folder. You can always also use Manual Install method which needs less free space on the flash drive.

No idea I am afraid. From what you have said I assume you can get the webUI page up for the container to see the MyMediaForAlexa console and setup pages? For me from their it seemed to "Just Work" and I do not remember having to do anything special other than connect the container to my Amazon account and that went through without issue. You may need to ask in the MyMediaForAlexa support forums (although not sure how active they are). In terms of scanning I assume you have the "Enable Watch Folder Autoscan" set to On under the settings for MyMediaFor Alexa For reference I have 2 instances of this container set up - one for music and one for audiobooks. I have attached the XML templates (from /boot/config/plugins/dockerman/templates-user) for my instances in case you want to compare them to yours although it does not sound as if this is where you have problems. my-MyMediaForAlexa-BOOKS.xml my-MyMediaForAlexa-MUSIC.xml

Those instructions are for array disks (not for pools). Also since you say your ‘cache’ pool had two disks in it it could not have been in xfs format as that is only allowed on single device pools. As was said provide your system’s diagnostics zip file to get informed feedback.