trurl

Post new diagnostics.

Doesn't look like you are having any flash problems in those. Are you booting from a USB2 port? Recommended. Your cache is full and that is probably how you corrupted libvirt. Your isos share has files on cache, but it is cache-no. Mover ignores cache-no and cache-only shares. Set it to cache-yes and run mover. The only other things on cache are appdata, domains, and system, and those should be on cache. Not clear what could be filling it unless you just have things setup wrong and are writing a lot of stuff into appdata. But dockers are currently disabled, don't know if you had some running before or not. Go to Shares - User Shares and Compute All. If it doesn't produce results after a few minutes, refresh the page. That will show how much of each disk each user share is using. Post a screenshot.

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

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

Maybe. Probably makes more sense for you to start your own thread with more details and your Diagnostics.

Don't use this, but in general, container ports can't be changed. Instead you have to change the host port that container port is mapped to.

Old drives that you already have may be OK, but you need to understand that in order to reliably rebuild a missing drive, every bit of all other disks must be reliably read. You should test old drives before trusting them. Unraid will monitor SMART of your disks and if any don't look good will warn you. Pay attention to those warnings.

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

Stop array. Go to Settings - Global Share Settings. Remove everything from Included disks and set disk shares to auto.

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

Settings - Docker, disable. Same for VM Manager. Then no appdata or system files will be in use. Run mover. Mover also won't overwrite duplicate files. Those sometimes have to be cleaned up manually. You can change the default boot option at Main - Boot Device - Flash - Syslinux Configuration.

Probably more than enough if you're careful how you use it. Many people seem to not give any thought to how they use cache, and just try to cache everything all the time. Don't cache the initial data load since cache won't have the capacity to hold it all, and it is impossible to move from cache to the slower array as fast as you can write to cache. Mover is intended for idle time. Your appdata, domains, and system shares belong on cache and should stay there (and will unless you change their settings or fill cache up). This is so your dockers and VMs won't have their performance impacted by the slower parity writes, and so they won't keep array disks spinning. I have a similar capacity in my cache pool. I cache very little. My dockers as noted, and my plex DVR since there is some benefit to SSD speed when trying to record and playback at the same time. Most of my other writes are scheduled backups and queued downloads, so I don't care if they take a little longer to write since I am not waiting on them. They go directly to the array where they are already protected by parity. Other people will have other use cases, but the main point is, think about it instead of caching everything all the time.

Were you intending to run the Nvidia version of Unraid? The Nvidia plugin installs a custom build of Unraid that includes the Nvidia drivers. If you just upgrade Unraid, you get the standard Unraid build and you no longer have the Nvidia Unraid build. You must use the plugin to select the Nvidia Unraid version. This is explained repeatedly in the Nvidia thread.

OK, back to your docker run. I don't use this docker, but that looks like it might be OK. The other piece of this puzzle though is the paths you configure within the application. If the application is writing to a path that isn't mapped, it is writing into the docker image. The paths the application uses must exactly match (Linux is case-sensitive) the container paths in the docker mappings. And only absolute paths (beginning with /).

I've certainly explained it many times. Mover ignores cache-no and cache-only shares. Mover moves cache-yes shares from cache to array. Mover moves cache-prefer shares from array to cache. This is the one you want. Mover cannot move open files, so if Docker or VM services are enabled (in Settings - Docker and Settings - VM Manager) it won't be able to move your system files. Mover will not overwrite duplicates when it moves. Sometimes this will require manual cleanup.

See what happens if you make sab download to a disk in the array.

Take a look

Do you have an attached keyboard and monitor? See this "Need Help?" sticky pinned near the top of this same subforum for ideas on how you can get us more information. Full diagnostics zip file preferred.

Does it happen in SAFE mode? Very likely unrelated, but your appdata and system shares have files on the array.

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

I wouldn't want to risk running a server with memory problems. Everything goes through memory, your data, the executable code, everything.

... Mar 26 23:10:15 JoTower emhttpd: error: put_config_idx, 609: Invalid argument (22): fopen: /boot/config/shares/\Tv Shows\files.cfg Mar 26 23:10:15 JoTower emhttpd: error: put_config_idx, 609: Invalid argument (22): fopen: /boot/config/shares/\media.cfg Mar 26 23:10:15 JoTower emhttpd: error: put_config_idx, 609: Invalid argument (22): fopen: /boot/config/shares/\movies\plex\files.cfg ... It looks like you have created user shares with invalid characters in their names. This is probably something you have done accidentally with your docker mappings. Any folder at the top level of any disk is automatically a user share, and if you specify a path at the top level of a disk or at the top level of user shares, it will automatically be created and that top level folder will be a user share. Take a look at all of your docker mappings and see if you have something like that. Maybe you already fixed it, but you still have those accidental user shares hanging around. You need to get rid of them and figure out what is creating them so it doesn't happen again.

I don't know if we can presume that is in RAM or not. If it were /tmp for the host then it would be, but since it is inside the container it might be be stored in the docker image instead of RAM. There is plenty of instruction here for doing it right.

You want your docker image on cache so your dockers won't have their performance impacted by the slower parity writes and so they won't keep array disks spinning. There is no reason to protect docker image because it is easily recreated, and it isn't very large so there is no good reason to not have it on cache and plenty of reason to have it on cache. Does Mover really need to run that often? It really is best if you have it run at idle time, so it isn't competing for the disks. And, there is no way to move from cache to the slower array as fast as you can write to cache, so if you are writing so much to cache that you think you need to run it that often, maybe you should reconsider how you use cache. There is no requirement to cache writes to user shares. Most of my writes are scheduled backups and queued downloads. I don't care if they are a little slower since I'm not waiting on them anyway. So, those are not cached. Instead, they go directly to the array where they are already protected. I mostly use cache for my appdata and docker image so my dockers perform better and don't spin the disks, as noted. I also use cache for my plex DVR since there is some benefit to the SSD speed when trying to record and playback at the same time. My normal user share writes are not cached.

What are you using for this?