trurl

What are you editing and how?

Are you editing /etc/resolv.conf yourself or something? I think normally that information would come from Settings - Network Settings in the webUI. The Unraid OS is in RAM. It is unpacked fresh from the archives on flash at each boot into RAM, and then settings from the webUI, which are stored on flash, are applied. Only /boot (the flash drive), and /mnt (the mounted disks and user shares) persist. Any change you make to /etc and other OS folders will not persist since the OS is in RAM and any changes you make outside the webUI that affects any of that are not retained. If you have some special need that can't be handled with the normal configurations in the webUI, you can write a script to apply those changes, and use the User Scripts plugin to run the script at boot.

Go to Settings - Docker and disable. Go to Settings - VM Manager and disable. Set appdata, domains and system shares to cache-prefer. Probably better set your downloads share to cache-no at least for now. Run mover. Wait for it to complete. Post new diagnostics.

No that is not ideal. Your appdata, though you have set it to cache-only, currently has all of its files on the array. Ideally all its files would be on cache. And your domains and system shares are cache-no with all their files on the array, but ideally they would have all their files on cache and set to cache-only. As I said, it will be a multi-step process to get this changed, with possibly some manual cleanup down at the disk level. Mover ignores cache-only and cache-no shares. It moves cache-prefer files from array to cache, and moves cache-yes shares from cache to array. To get those appdata, domains, and system shares moved to cache they will have to be set to cache-prefer. But, mover also cannot move open files. So before they can be moved, dockers and VMs will have to be disabled; not the individual dockers and VMs, but the services themselves in Settings - Docker and Settings - VM Manager. Then finally, mover won't move duplicates, so if some of these exist on both cache and array you will have to delete the duplicates from the disk level. I was glad when we were working through your problems last week that you did not have these problems at that time. Now you have made them and will have to clean them up if you want the ideal setup for your dockers and VMs.

Your syslog was being filled with these: Apr 29 07:13:20 Tower root: error: /plugins/preclear.disk/Preclear.php: wrong csrf_token Apr 29 07:13:26 Tower root: error: /plugins/preclear.disk/Preclear.php: wrong csrf_token which is explained in this FAQ:

You have different upper/lower case in the container paths

That doesn't look too bad. You typically would want a lot of processing power for post-processing downloads. That shouldn't make it crash though. I don't have nearly that many cores but it is not uncommon for some to go red like that. Did you install this CPU and cooler yourself?

I took a quick look at your diagnostics. Cache is something we already discussed. Another thing that can help is more RAM. You can setup your plex docker to transcode to RAM, which is obviously faster than even SSD cache.

It sounds like what you really have in mind as far as the actual data isn't really a migration, but simply upsizing some of your data disks. The usual way to "upsize" a data drive is to simply replace the drive with a larger drive and let it rebuild. No need to copy anything at all. The only time you might want to do something a little different than just rebuilding a disk to a larger disk is if you intend to finish with fewer disks at the end of this "migration". Then you might do some copying from some of the disks you want to remove to some of the already upsized disks before removing them. I always say each additional disk is an additional point of failure. And more drives requires more hardware to support them. And larger disks perform better than smaller disks and are less expensive per TB. So I always encourage upsizing disks instead of adding disks. Maybe with the increased capacity from upsizing you don't really need any of those original 2TB disks. /usr is actually an operating system folder on RAM. The user shares are in the user folder under /mnt (and the disks are also under /mnt). There are some reasons for that advice that don't apply in all cases. One reason is so you don't mix user shares and disks when moving / copying, which can result in data loss. Another reason is because it is simpler to let Unraid decide which disk to put something in accordance with user share settings, so folders can span disks, such as when you have more movies than will fit on a single disk, they can all still be in the same user share. But if all you are really trying to do is upsize data disks then much of that is probably moot. And if you do intend to remove some disks after upsizing others, then moving from those disks to the upsized disks makes perfect sense because your purpose is all about which disks are used. If you can have different people streaming from different disks then you could expect that to perform better. For example, if you had kids movies and movies for everyone else, then maybe you could have separate user shares for those, and set the shares to include different disks. Just depends on your specific needs. If everything were on one disk then there would definitely be some number of streams that would strain the capabilities. Not sure where that line is, but a few might be OK depending on other factors. You will definitely want to setup the builtin WireGuard VPN so you can manage it remotely. No, that's not how it works. Your media will typically be served from the array disks. Cache can be used to improve performance of the plex docker though, since its library will be on the appdata user share and its executable code will be in the system share. Those shares can be setup to stay on cache where they will not be impacted by the slower parity writes, and where they won't keep array disks spinning. But there is no mechanism to move your media to cache as needed for playback. I do my Plex DVR to cache (SSD pool) since there is some performance benefit when trying to record and/or playback multiple DVR programs at the same time. I may delete the recording after watching it, or if I want to keep it gets move to other user shares on the array. My CPU is several years old now also. It is a 4th generation i5 (Haswell). But it has builtin iGPU so I can transcode with that. My specs are probably a little weak compared to many on the forum, but it is working for me. Often only 1 stream, seldom more than 2. Even if you have GPU transcoding there is still definitely some work for the CPU. I think GPU usage varies depending on the specific codecs for example. And there is more to performance than just CPU/GPU of course. Newer motherboards, RAM, even disks can all contribute to greater performance.

We didn't have to go into fixing that in your other threads because you hadn't changed them from the default cache-prefer, and those shares were all already all on cache where they belonged. Now you have some of each of them on the array where they will impact your docker / VM performance due to the slower parity writes, and where they will keep array disks spinning. And it is a multi-step process getting them all on cache, possibly with some additional cleanup. But I guess we can go through all that later. Have you taken care of these Ryzen tweaks?

So is this a new install on the same flash? Why did you change the Use cache setting on appdata, domains, and system shares from the default cache-prefer?

You have your appdata, domains, and system shares setup wrong. Do you have Dynamix System Temp plugin setup? Or do you have some other way to monitor the temp, such as IPMI?

syslog.1 isn't getting big because it has already rotated. It is as full as it's going to get. Since you are likely out of space you probably aren't even getting anything in the current syslog. Copy that syslog.1 from /var/log/syslog.1 to one of your user shares where you can get it from your PC, then reboot and get new diagnostics and post them along with the zipped syslog.1

Is this a different server than the one I was helping you with last week?

That is a docker, not a plugin. So this does not apply: Flash drive problem is another likely cause of webUI issues. Make sure you are booting from a USB2 port.

What are these shares anonymized as d----------p and T-------e ? As I explained, mover ignores cache-no shares. If a share already has files on cache, setting the share to cache-no will not get any of those files off cache. The user share settings only applies to newly written files. So if a share has files on cache, and you set it to cache-no, no more files for that share will be written to cache, but mover will ignore the share and so those files will never be moved from cache.

If you don't know whether or not a notification is something to worry about, it is something to worry about and you should ask. That disk should be showing you SMART warning on the Dashboard and if you click on the disk in Main and go to its Attributes, you will see several highlighted. You should setup Notifications to alert you immediately by email or other agent when Unraid detects a problem. Yes. I assume you meant Krusader there. Have you used it with an Unassigned Device before?

Is this why your cache is so full?

Mover moves cache-yes shares from cache to array and moves cache-prefer shares from array to cache. Mover IGNORES cache-no shares and cache-only shares. You have cache-no shares anonymized as d----------p and T-------e with files on cache and they will not be moved.

Unraid is NOT RAID, you will never get RAID5 speeds on Unraid. Unraid has other advantages.

If you don't answer our questions how can we help you? If you insist, but wouldn't it be easier to fix the problem? And wouldn't it be better to find out the cause of the problem?

There was a change to the folder/file permissions between V4 and V5. This is discussed in that wiki here: https://wiki.unraid.net/Upgrading_to_UnRAID_v6#New_Permissions https://wiki.unraid.net/Upgrading_to_UnRAID_v6#File_systems That is how most people did it. You just need an empty drive you can format to a new filesystem, whether a spare, or just moving files off a disk already in the array. Then move files to it so you empty another drive, reformat that empty one, repeat as necessary. The unBALANCE plugin can help with that.

That slower speed seems reasonable if you have parity and are using the default parity update method. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Disk2 is one of the very worst SMART reports I have ever seen. It is pretty old though. Did this happen all at once, or have you just been ignoring this problem? Do you have Notifications setup? This seems like a good plan, and in fact, what I usually recommend instead of trying to shuffle files from the emulated disk to other disks in the array when you are already unprotected. Once you have the backup, might as well New Config without the disk, reassign disks if you want to fill in that gap left by the missing disk2 (making sure you don't change parity assignment, of course), and go ahead and rebuild parity. Then everything is protected again and then you can copy the data from that backup.

Cache looks OK to me. I did notice you had given 35G to your docker image though, which is why I asked about filling it. 20G should be more than enough and its usage shouldn't grow. Go to the Docker page, click Container Size button, and post a screenshot.