trurl

Not really addressing your point, but your post makes me question if it is really a good idea to want to use so many "just laying around" small disks. Parity by itself can't rebuild any failed disk. ALL bits of parity PLUS ALL bits of all other disks must be reliably read to reliably reconstruct a disk. More disks means more opportunities for problems. "Just laying around" disks may be old and already have issues. Larger disks will typically perform better due to increased density. Just some things to think about.

I agree this should be fixed. But DO you have other monitoring? It doesn't look like you have another agent configured from that screenshot. That is the point I was making. You need to get notified.

Rather than trying to get these to go away, you really should configure it so you get at least warnings and alerts by email or other agent. You need to know immediately when Unraid detects a problem instead of waiting until you happen to see it in the webUI. People who don't know when they get their first problem are the people who wind up with multiple problems they can't recover from.

What do you mean you don't use the appdata share? So what cache-prefer share are you using then? While it is possible to do things differently, I have to ask why you would want to go against the conventions. It is just going to make it harder for you to use the community dockers, and harder for people to support you. Are you sure you know what you're doing?

You can set any of your User Shares to not be exported on the network, but they will still exist on the server because their folders are still there. You can change the name of your shares, which will rename their folder(s). Probably not really relevant to your problem though. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post.

You can't delete any shares that aren't empty, and user shares are just the top level folders on the disks. So to delete a share you would have to delete all of its data first. He was talking about his server name. That said, SMB does have some idiosyncrasies about names that sometimes get people in trouble. And Microsoft has been tinkering with SMB on their side that sometimes breaks access with non-Windows computers. Maybe you should

FTFY

Did you even bother to read the link I gave you? It explains exactly how to get the information I was asking for, the docker run command.

Any other information you can give us? Your docker run command, for example?

Since this thread is nearly 5 years old it might be worth considering if there are better methods since. Instead of adding to the go script. the preferred method of executing a script is with the User Scripts plugin. You can configure when your script runs, including at boot time.

What do you mean still? Do you mean you tried something and that didn't work either? You really haven't told us anything at all except it doesn't work. The whole point of the link I gave you was to tell you how to get us more information to help you. We need more information.

No it is inside the plex library path. In other words, in appdata.

First link in the Docker FAQ:

no

You may have to refresh the page after a while. I just did it on mine and it didn't really come back with the results until I refreshed.

I see. You gave plex access to all of your data. I just had not looked at the mounts inside the container when you do it that way. The "advantage" of giving plex access to all your data is it makes it so you don't have to bother with understanding volume mapping.😉 Actually, I do that myself, and I understand volume mapping very well. However, instead of giving it access to /mnt as you have done, I give it /mnt/user. In other words, I am giving it all my user shares, whereas you are giving it all your disks and all your user shares. Plex is unlikely to break anything like that, but in general I wouldn't give anything direct access to my disks, mainly because you should never mix disks and user shares when managing files. Don't change it though or plex won't be able to find the media it has already scanned.

I don't use ECC and I basically never get sync errors. Do you have a lot of unclean shutdowns? Do you often get read/write errors on your disks due to bad connections, etc. Do you have an UPS?

That's the right page but not the screenshot I wanted. Did you click the Compute All button at the bottom of the User Shares section? After clicking Compute All it determines how much of each disk each user share is using and displays it. It will take some time to get the result.

Post your docker run command as seen here: https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

No that is the right one. I was just confused by what I saw. Why are you mapping each of your disks individually? Post your docker run command as seen here: https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

Actually, this won't do what was intended. Mover won't touch cache-only shares. Before giving you the correct procedure, lets figure out what your situation really is in more detail. Go to Shares - User Shares and click Compute All. When it is done, post a screenshot.

Those results look like they were entered at the Unraid console, not the docker console. Also, please attach instead of linking to an external site.

Have you tried a different browser?

If you're doing a correcting parity check, then it should fix all sync errors, and the next check should be zero.

Are those parity sync errors? What about the errors column on Main - Array Devices?