trurl

Better to just make separate user shares, one for movies, one for tv, etc. Then you can manage them separately. Each user share has settings for included disks, split level, and many other things.

Please attach diagnostic to your NEXT post instead of linking to external sites.

Just make the SSD all cache. Cache can have data that stays there depending on a setting for each user share. And with regard to cache, it is all about each user share and that setting as far as how cache gets used. See the Wiki Overview for a good start on understanding cache and a lot of other things about Unraid:

Belongs on the forum instead of in the reports so I have copied it there and closed the report.

Belongs on the forum instead of in the reports so I am copying it there and closing this. Changed Status to Closed Changed Priority to Other

Since your are coming from a version before 6.5, see these notes and take care of anything needed before upgrading: https://forums.unraid.net/topic/66327-unraid-os-version-650-stable-release-update-notes/ Before doing anything, make a backup of your flash drive. Might be a good idea to uninstall any plugins, since they will also be way out of date. You will have to go to the Downloads page linked at the top of the forum and download a new version, then take all the bz* files from the download zip and put them in the top folder of your flash drive, replacing any files already there.

You can go directly to the correct support thread for any of your dockers by clicking on its icon and selecting Support.

Not sure why you are telling me that. Perhaps you don't understand my explanation above. It is the settings within the application itself that must exactly match your mappings, specifically the container path in your mappings. For example, if your deluge docker has /download mapped to /mnt/user/Download, but within the deluge application itself you have it set to use /Download, then that won't work because /download and /Download are different paths. The application must use the path specified as the container path in the mapping.

Have you seen this FAQ? https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

I think unclean shutdown parity check is noncorrecting. Unclean shutdown often results in a small number of parity errors. You should try to avoid unclean shutdown and in this case it seems an UPS would have prevented it. The large number of parity errors you got on that other check suggests you had done something to invalidate parity. I do monthly noncorrecting parity checks. Then if parity errors are detected (rare) and there doesn't seem to be any other problem that might have caused them, then a correcting parity check. Finally, after parity errors are corrected, another noncorrecting parity check to confirm there are exactly zero parity errors. If not then you have some other problem which might be diagnosed by examining diagnostics. We would need the complete syslog during those parity checks for comparison so no rebooting. Bad RAM is one possible reason for not being able to get to zero parity errors, for example.

Figuring out what any of those are may not be worth the trouble. Do you have backups of anything important and irreplaceable?

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post.

I know this is several days old now, but I felt it needed commenting on. Are you saying that your previous parity check had errors? Was that a correcting parity check? Exactly zero parity errors is the only acceptable result. If you get any errors at all you must correct them, then you should check again to make sure there isn't still some problem. If you have parity errors how can you expect to rebuild a disk? One possible result of rebuilding a disk when you have parity errors is a corrupt filesystem and unmountable disk on the rebuild.

I have replied on your other thread.

The appdata is only one piece of the puzzle. The docker image contains the executable code for your dockers. According to your settings in previous diagnostics that docker image was probably on cache. But docker image isn't important since the executable code can be downloaded again. The templates which contained all the settings you made for each docker (mappings, etc.) was in the config folder on flash. Were you able to restore that config folder to your new flash?

It looks like what johnnie said. Your docker image is 30G now. Did you increase its size? Have you been filling it? 20G should be more than enough and if usage is growing you need to fix something, making docker image larger will only make it take longer to fill.

Not clear from the diagnostics if disk5 is unmountable or not since the array can't be started in that state so nothing is mounted. If necessary we can try to repair the filesystem on disk5 after disk1 is rebuilt. Currently Unraid considers disk5 disabled and disk1 wrong. It wants to rebuild disk5 based on the correct disk1 and all other disks. If former disk1 is truly dead I guess you will have to try to rebuild disk1 based on disk5 and all other disks. You will have to do the invalidslot command. In your case the invalid slots are 1 and 29 (29 is parity2 which you don't have). This is a good thread on that: https://forums.unraid.net/topic/92080-solved-best-way-out-of-this-jam/

That looks OK, depending on your answer to this: Plex doesn't write much except trancodes and possibly DVR if you use that. Do you use DVR in Plex? Maybe one of your other dockers is to blame, such as a downloader since they write a lot of data. There are basically 2 ways you can cause a container to write where it shouldn't. If the host path in a mapping for any container isn't a disk or user share, then that host path is in RAM just like the rest of the Unraid OS, and if the application writes to the corresponding container path, it is writing into RAM. More relevant for your issue, though. If an application writes to a path that doesn't correspond exactly to a mapped container path, then those writes go into the docker image. It is important to remember that Linux is case-sensitive and so case matters when specifying a path. And you must also make sure any application paths are absolute (or possibly relative to another absolute path already specified). Specifying the wrong upper/lower case, or specifying a relative path, within the application settings is the most common reason for filling docker image. Note that this isn't really about the mappings, it is about the paths specified within the application itself not matching the mappings.

Post new diagnostics

Diagnostics are generally more useful if you have the array started, since many things aren't really working with the array stopped.

Did you try the links in the first post of this thread?

You are confusing 2 separate things, the appdata share, and the docker image. Typically the "config" folder for a docker is mapped to appdata. Plex appdata can become a bit large and what you have seems fine. On the other hand, docker image should not grow and 20G should be more than enough. Making it larger won't help, it will just make it take longer to fill. Go to Tools - Diagnostics, attach complete Diagnostics ZIP file to your NEXT post. Also, docker run command for your plex docker as explained in this very first link in the Docker FAQ: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564345 Also, the transcode directory setting within the plex application.

Go to Tools - Diagnostics, attach complete Diagnostics ZIP file to your NEXT post. Also, docker run command for your plex docker as explained in this very first link in the Docker FAQ: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564345

Sounds like a possibility Tools - Diagnostics, attach complete Diagnostics ZIP file to your NEXT post. Also, docker run command for your plex docker as explained in this very first link in the Docker FAQ: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564345 Also, the transcode directory setting within the plex application.

That user hasn't visited the forum in many months. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post.