trurl

Unfortunately, the diagnostics from that old version of Unraid you are using doesn't give us any information about what user shares actually exist. You seem to have over 1000 .cfg files (a record as far as I have seen) in config/shares on the flash drive, many with anonymized names that seem unlikely. I suspect at some point (or possibly different ones at different times) you accidentally created a lot of user shares. Any folder at the top level of cache or array is automatically a user share. The reason I bring this up is because it can make it difficult to give advice regarding your user shares since it looks like you have so many. Open up that diagnostics you posted and you will see what I mean. How many user shares do you actually have?

Hey "Advanced Member"😉 The other things I mentioned are not technically errors, just less than ideal configuration of your dockers and VMs. Do you actually have any VMs?

This thread you have posted to is nearly 8 years old and is in the Legacy Support (unRAID 5 and Older) subforum. Start a new thread in General Support and post your Diagnostics.

Unfortunately viewing sigs is disabled by default by this forum software. Click on the dropdown next to your user name at the top right of any forum page, and select Account Settings. There you can enable viewing sigs, and create your own sig.

Good luck! Maybe those videos linked above will help you ask better questions.

What do you want the VMs to connect to? We seem to be going around in circles here. Each VM is a (virtual) computer. A VM can connect to the internet, it can connect to other machines on your network, including other VMs on the server. A faster connection is just that, a faster connection. There is no specific speed requirement for the network in order for you to have VMs. It would even be possible to setup a VM and then never use that VM to network with anything. I don't really understand why you are asking about this. I assume you have some experience with home networks and obviously you can access the internet. The VMs are just computers that would use your network in the same way any other computer would use your network.

The VMs themselves don't need internet to work with the video cards, etc. They only need internet the same way any computer needs internet. Your questions make me wonder how much you will have to learn to even get started on this though. Have you ever built a PC?

Not that much of a bullet to bite if you do it correctly. For future reference. Go to Settings - Docker, disable dockers, then you can delete docker.img on that same page. Then on that same page, you can edit its path and enable docker to recreate it at the new path. Then the Previous Apps feature on the Apps page will add your dockers back exactly as they were. Since your templates (mappings, etc) are on flash, and the working storage (appdata) of the applications are in the user share, Previous Apps together with these will download your dockers executable code (the only thing missing, which is what winds up in docker.img) and set them up exactly as before.

Assuming the hardware is well chosen and works well, there is still a bit more that needs to be setup on the software side of it to actually make this happen. Unraid isn't really a multi-user operating system, but it can host VMs (Virtual Machines), which are like separate computers. These VMs can have their own monitor, keyboard, etc.

You connect Unraid by ethernet to your router, and other computers on that router's network can access the Unraid server by ethernet or wifi. Maybe I am still missing something because what I have just described is pretty basic home networking.

The point of this is that for cache-yes or cache-prefer shares, when cache gets too full (less than Minimum remaining as set in Global Share Settings), it automatically switches to writing to the array instead.

👍

Your user share named "all" still has files on cache. Do you know how to see what those are?

You might consider replacing parity with a larger drive and reusing parity as a data disk. That way you will be able to use larger drives in your array, whether as replacements or in new data slots. 8TB seems the be the sweet spot at the moment as far as TB per dollar.

It is impossible to move data from fast SSD cache to the slower HDD parity array as fast as you can write to fast SSD cache, no matter how large your cache is. You just need to reconsider how you are using cache. First of all, don't cache the initial data load. Cache only gets in the way because Some people even do the initial data load without parity since parity slows down writes. After the initial data load, consider whether you really need fast writing to some of your shares. Many of the writes to my server are from unattended processes. Since I am not sitting there waiting for them to complete, no need to cache them. Finally, mover is intended to run during idle time because Instead of being concerned with how much you can write in an hour, it would really be better to consider how much you might write to cache (and how much you might instead write directly to the array) during the day so it can be moved to the array at night when you aren't writing new files to cache. If you want more specific advice on how to avoid filling cache, post your Diagnostics. Tools - Diagnostics, attach complete Diagnostics ZIP file to your NEXT post in this thread.

Disk firmware has no way to know about filesystems, that is at the OS level.

yes just include the next disk in the share. That is similar to what I do except I don't use fillup.

👍 yes. As for getting someone else to check your connections I will let you decide. Since you don't need the capacity of a third drive yet you might wait to add that later. I always say each additional disk is an additional point of failure.

How are you accessing it? I don't see WireGuard plugin in your diagnostics. If using OpenVPN docker, for example, then there is also going to be some trouble fixing those other things I mentioned since you will have to disable dockers.

I'm a windows guy also. This is about using Unraid, not the underlying linux OS. The split level setting is about a user share, not about a drive. In fact, the whole point of split level is to keep certain files together so they don't go to other drives. For example, suppose you have a music collection, and you are old-school and like to listen to "albums". You are playing an album, and the first several songs are all on the same disk. So it plays the songs from that disk, but since the other disks aren't being used, they are spun down. Now it gets ready to play the next song from the album, but that song has been allowed to be split to another disk. Since that other disk is spun down, you have to wait for it to spin up before the song can begin playing. Same principle when binge-watching TV series. Some people will prefer to keep all the files for a specific TV series on the same disk so there is no spinup delay between episodes. I don't care about split level, mostly because I have my whole music collection restricted to a single disk anyway, and I don't care about TV much. So for most user shares, I just set split level to allow splitting anything. You have split level set so it WON'T split anything. Instead, you have told it that you will manually create new folders on other disks when you want files to go to other disks. You can click on the label for any setting in the webUI to toggle help for that setting. For simplicity, try changing it to "Automatically split any directory as required".

Change the split level on your TV share!!!

yes, did you understand my reply? So does this mean you are good now?

Why are you ignoring us and just repeating yourself ??

Mover can't move open files, and the files are open all the time when Docker and VM services are enabled. Also, your domains share is actually set to be moved from cache to the array. There are some specific things that need to be done to get this all done. Let me know when parity rebuild is done and we can work on it.

It makes it impossible to coordinate replies