trurl

Didn't notice any errors in syslog. Looks like you just added and formatted 2 new disks. Didn't look at SMART. Do you have any SMART warnings on Dashboard for any of your disks? Disks 1,2 are very full and reiserfs. Moving files involves writes to the destination obviously, but it also writes to the source, since it has to delete the source file after it is copied to the destination. Possibly you are just seeing the expected inefficiencies of writing to full reiserfs disks.

Linux is case-sensitive so /mnt/user/Media is a different path than /mnt/user/media. Using the wrong upper/lower case in a docker mapping is a very common way to get shares with default settings accidentally created.

Probably you were not looking at the same diagnostics you posted. Maybe you were looking at new diagnostics you had collected without anonymizing them. If you actually download those you posted earlier you will see what I was talking about with the (1), but in the end the effect is the same. I think if you don't anonymize you get to see them as they actually exist in the system, with upper and lower case. They were recreated as default shares because they were top level folders on cache or array that didn't have a corresponding .cfg file. Don't really know what was going on. Your latest diagnostics don't seem to have any duplicates. What do you get from the command line with this? ls -lah /mnt/user

locked

How (give very specific details) are these files being created?

I copied this to General Support and closed the report. We can reopen if it becomes apparent there is actually something going on but I don't think this qualifies as a bug report at this time. For future reference, here are the guidelines for posting a bug report: https://forums.unraid.net/bug-reports/stable-releases/report-guidelines-r68/

The only reason the 16TB winds up being parity is because it cannot be the data disk if your parity disk isn't at least that large. If/when you get that 2nd 16TB then one of them could be a data disk. Note parity only has to be as large as the largest SINGLE data disk, it doesn't have to be as large as all of the disks together since parity isn't a backup of your data. All disks are used by the parity calculation to rebuild a disk. And if your parity is that large, it is easy to replace any smaller data disks with a larger disk up to 16TB since parity is already that large. Two of the great advantages of the way Unraid does things vs some other system is that Unraid allows you to mix disk sizes in the array, and it is very easy to add or replace disks without rebuilding the array.

Go to Shares - User Shares and click Compute All. It will take a little while to produce the result. That will show you which disk each user share is using. By default, the appdata, domains, and system shares are the ones used by dockers and VMs. You want these shares to be all on cache with nothing on the array. Those are the default shares as I said, but it is possible to make something else happen when you first enable the Docker and VM Services. The settings for where these things go are in Settings - Docker and Settings - VM Manager. Or you can just go to Tools - Diagnostics and attach the complete Diagnostics zip file to your NEXT post if you want us to take a look at how you have things configured.

You can go directly to the correct support thread for any of your plugins by going to the Plugins page and selecting the support link displayed with that plugin. And for your dockers, you can just click on the icon for the specific docker and select Support on either the Docker page or on the Dashboard. Plugins and Dockers also have support links displayed on the Apps page with their listing.

If you want to run the current stable version of Unraid you would need to install OpenVPN docker or something similar, I'm not sure what else is available now, since we have literally hundreds of dockers to choose from so there may be other choices for VPN. Many new routers also have VPN builtin. If you install the latest Unraid release candidate, WireGuard is builtin and many of us are already using that for VPN with good success.

If you install cache before setting up dockers / VMs they are there by default. If you setup dockers / VMs without a cache drive installed then of course they would have to go to the array. And it takes a little work to get them moved to cache because you can't move open files. Have you setup any dockers / VMs yet?

Can your server reach the internet?

Parity must be at least as large as the largest single array disk, so with those the 16TB would have to be parity. The SSDs belong in the cache pool or Unassigned.

You should use the cache for dockers and VMs and not for caching user shares since it doesn't have enough capacity. And if you really want to remove a disk I would recommend removing parity2. You really want your apps on SSD cache so they perform better and don't keep the array spinning.

Do any of the disks show SMART warnings on the Dashboard? Be sure to setup Notifications to alert you immediately by email or other agent as soon as a problem is detected. Fix a problem as soon as it occurs so you don't wind up with multiple problems that are more difficult to recover from. And install Fix Common Problems plugin also.

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

Also be sure to boot from a USB 2 port.

That is the standard way of working with dockers on Unraid. Most people are probably mostly unaware of doing it from the command line or manually editing templates.

There is a whole "sticky" thread about these issues pinned near the top of this same subforum: https://forums.unraid.net/topic/53172-windows-issues-with-unraid/

Not a stupid question at all. Here is the Docker FAQ post about that: https://forums.unraid.net/topic/57181-docker-faq/#comment-566084 As mentioned there you should also create a support thread where you can support it.

Do you have backups? I don't have any experience with your current setup, but Unraid must format any disk it will use in the array or cache pool, so you will need some way to get some of those disks free if you intend to reuse them. Maybe you can get rid of the duplication and if that leaves you with NTFS disks with your data you could make an array out of the free disks then mount the others as Unassigned Devices to copy their data.

I recommend removing all those and just starting a new array without them. I always recommend fewer larger disks instead of more smaller disks. More disks require more ports, more power, at some point more license, and most importantly, each additional disk is an additional point of failure. And larger disks perform better due to increased density. Haven't checked the SMART for each of those, but I suspect they are also old. Have you tested all of your disks? Every bit of every disk must be reliably read to reliably rebuild a disk. Don't install lots of disks just because you have them laying around. Only install what you need for capacity. It is easy to add disks later, or to replace a disk with a larger disk.

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

You can name them whatever you want simply by setting the Name field on the Add/Edit Container page. If you notice, that is one of the parameters in the docker run command. What he said. Since you have specified a different appdata path for the other docker then you haven't actually got any libraries added yet. The appdata contains the plex library database. Since this is a new appdata it is a new installation of that plex library database.

Just thought I would mention that SSDs in the array can't be trimmed, and if you intend to have parity in the array you don't want to have SSDs in the array anyway. People usually put SSDs in the cache pool. But you must have at least one disk in the array so if this is the only disk you intend to have then I guess it is the only way to do it.