trurl

That is where your docker templates were stored. Do you have any flash backup?

Post your docker run command as explained at this very first link in the Docker FAQ:

Why haven't you done this? Have you done memtest?

You need to set this up slave so it will have the correct setting when you have an unassigned drive. Otherwise Krusader will not be able to work with that unassigned drive. If you have the mapping, which is reasonable so it will be available when you have an unassigned drive, then you must make the mapping slave or it won't work when you plug in an unassigned drive because if it isn't slave it can only work with disks that are already plugged in when you boot up (technically when the docker service starts). I would word this differently. The user shares ARE the root folders on cache and array. Cache itself has root folders that are part of user shares. user is all root folders on cache and array, user0 is only the root folders on array. User shares are how Unraid allows folders to span disks. Each root folder on cache and array is part of a user share named for that root folder.

Looks like your questions got answered, but to validate your shares are using the intended disks, go to Shares - User Shares and click the Compute All button. You may have to wait a few minutes for the results. Refresh the page if results don't appear after a while.

Looks like you're having the same problem as this thread: Not sure if this could affect preclear or not but it has been spamming your log. Why do you have 75G allocated to docker image? Have you had problems filling it? 20G should be more than enough. Also, your appdata has files on the array instead of all on cache as it should.

On mobile now so can't look at Diagnostics, but you probably have raid1 mirror (the default) for cache pool so total capacity is only equal to the smaller disk. In order for a user share to overflow, cache must have less than Minimum Free. I'm sure others will respond but I will check back.

What version of Unraid do you currently have installed? If it is older than 6.5 there may be some other things you need to take care of for the update.

There is no way to enter the GUID. It is a unique identifier for a specific flash drive and Unraid gets it from the flash drive that is plugged in. Sounds like you have bought a license for the GUID of that "pos freebie". If you want to use a new flash drive, you will have to do the transfer to get the license to work with the GUID of the new flash drive.

I'll leave the "format" question aside since format is something else entirely and should take less than a minute. I am guessing you have a vague idea of what format does. As for preclear, it can take a while, but there is no way it should take that long. You almost certainly have a hardware problem, such as bad connection. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post.

Attach your Diagnostics instead of linking to external sites. Thanks

I should have thought of this, since I have posted about just this "surprise" a number of times. Such as #2 here: https://forums.unraid.net/topic/61985-file-browser-in-webui/?do=findComment&comment=723474 The file is getting "repathed" to the same disk it is already on.

It already existed in the user share because cache is part of the user share. If the Media user share is cache-no, then writing to that user share will not write to cache. So something is configured somewhere to write to cache instead of to the user share. To answer a question left unanswered earlier since maybe it will help you figure this out: Mover doesn't know anything at all about any of your applications. It just runs according to its schedule, and moves cache-yes shares from cache to array, and moves cache-prefer shares from array to cache. Mover ignores cache-no and cache-only user shares, and it doesn't make copies.

OK, I see what you are talking about. I've never looked at it in the way you are currently since nobody has ever reported it that way. Everything looks normal to me. Here is the line from df.txt in your diagnostics system folder: Filesystem Size Used Avail Use% Mounted on ... /dev/loop2 20G 515M 18G 3% /var/lib/docker And here is an excerpt from syslog showing mounting of the docker image vdisk: May 6 10:16:03 Floater emhttpd: shcmd (281): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 20 May 6 10:16:03 Floater kernel: BTRFS: device fsid 79511e36-94bd-41bd-8672-2b87b831d708 devid 1 transid 322886 /dev/loop2 May 6 10:16:03 Floater kernel: BTRFS info (device loop2): disk space caching is enabled May 6 10:16:03 Floater kernel: BTRFS info (device loop2): has skinny extents May 6 10:16:03 Floater root: Resize '/var/lib/docker' of 'max' May 6 10:16:03 Floater kernel: BTRFS info (device loop2): new size for /dev/loop2 is 21474836480 Looks like just different ways of reporting the 20G 20 GiB = 21.4748 GB

Your /tmp:/transcode mapping looks correct and your Plex trancoder directory is /transcode, so that should be working. What I don't see is any evidence of this "ballooning". Do those screenshots still apply?

What evidence do you have that says It normally doesn't "balloon" in an nonvirtual Unraid, it just runs out of space.

No experience with that and whether running virtual disks within virtual disks might be an issue. And virtualizing Unraid isn't supported. There is a subforum here where other virtualizing Unraid users support each other. https://forums.unraid.net/forum/46-virtualizing-unraid/

Obviously something is creating that folder. Check your docker mappings.

You might run an extended SMART test on it.

Did you change something? According to diagnostics your docker image has 20G allocated, and is only using 515M. What do you have in Plex for transcoder directory? Screenshot please.

Settings - Docker, Disable. Then you can delete docker image on that same page and change its size to 20G. Also enable docker log rotation. Enable docker and docker image will be recreated with the new settings. Then go to Apps and use the Previous Apps feature which will reinstall your dockers exactly as they were.

CRC errors typically are a problem with the connection

Why have you given 50G to your docker image? Have you had problems filling it? 20G is more than enough unless you have some application misconfigured. Making it larger will not help with filling docker image, it will just make it take longer to fill. You also don't have docker log rotation enabled. But system share is all on cache so that is as it should be. There is a duplicate share name showing up in your diagnostics. Difficult to see exactly what happens sometimes due to anonymizing, but it looks like it is probably related to your appdata share. And these duplicates are something I see occasionally in diagnostics. There is a .cfg file on flash in config/shares that looks like it may belong to appdata or something similar anonymized as a-----a(1). The (1) is the reason I say it is a duplicate, because DOS naming conventions don't distinguish case so it gets renamed in diagnostics with the (1) appended. That .cfg file has settings for a share that doesn't actually exist on any disk. There is another share in diagnostics that does exist, on cache, anonymized as a-----a, but it has no corresponding .cfg file in config/shares. Take a look at your flash in config/shares and see if you can clear up this mystery. Also, all your array disks are very full as I'm sure you know. Nothing obviously related to your stated difficulty though, except the possibility that you have been filling docker image. You might try recreating docker image as 20G just to clean it out, then the Previous Apps feature on the Apps page will reinstall your dockers exactly as they were.

That is not the port Plex usually uses for remote access. Which plex docker are you using?

Diagnostics already includes SMART for all attached disks. Those diagnostics don't have the array started so there is a lot we can't tell since no disks or shares are mounted, etc.