itimpi

UnRaid will not rebalance (I.e. move) files between array drives regardless of whether SMB/CIFs is used or not. It does however have the rules for user shares that apply when copying files to user shares but these are not network specific. if your docker containers are mapped to user shares (I.e. locations under /mnt/user) the the same rules are applied for placing files as would be applied if files came across network.

SATA cable problems trigger connection issues which show up as UDMA CRC errors at the SMART level.

Reallocated sectors will always be internal to the drive in some way. The only external factor I can think off that might contribute would be borderline power.

Not sure it is wrong as if you have not given read or write access that implies to me no access however it would do no harm to make it explicit.

The whole zip file

You would need to use the 6.9.0-rc release to have support for the NIC on that board. The 6.8.3 release does not have the required drivers.

No - that is the file system overhead for creating an empty XFS file system with the latest Linux XFS drivers.

I’ve never had a problem doing this using Debian or Ubuntu. Never tried OMV but if it does not work there I would suspect the problem to be at the OMV end.

The is not how it works. The contents are only in RAM and will be lost on shutdown.

It almost sounds as if the upload speed from the remote server is not as fast as it is expected to be and that is limiting the overall transfer speed. have tests been done at the remote server to check that it can actually achieve the expected upload speed?

If you do want to try and work out what the files should be then the linux 'file' command can be used to at least give you the file type.

As long as you can tell what it is then just move it back to where it belongs. It often not that simple when items end up in lost+found as that typically happens because a directory entry was missing or corrupt and the file names are lost so random numeric names get assigned leaving it up to you to manually inspect files to work out what they are. Often not worth the effort unless it is important data.

Have you checked that the BIOS is still set to boot off the USB stick and has not reverted to something else as the default?

In this case it would be /mnt/user/appdata/roonserver/app that is the same as /mnt/cache/appdata/toonserver/app User Shares always appear under /mnt/user.

You cannot do all those changes at once and retain valid parity. If you want to retain valid parity throughout then the changes will have to be done incrementally taking much longer. If you are prepared to take the risk of running without party for a while then you can use Tools->New Config; assign the disks as you want them to end up and then start the array to build new parity based on the new disk set. The 2 existing data drives will be recognised as containing data and their contents left alone. The 2 new data disks (the old 5TB parity disks) will show as unmountable with unRaid offering to format them to create an empty file system so they are ready to store files.

Yes. I you think about it has to be emulated while the rebuild is in progress as the disk does not yet contain its final data.

If you want the cache to be ‘protected’ then you need to have multiple drives in the cache. It is never part of the array parity. there is also a plugin for doing periodic backups of appdata to a location you specify.

If you have a decent processor then the 2nd parity drive probably does not affect performance compared t' a single parity. However running with no parity at all DOES improve performance. It is also worth pointing out that having a parity drive does not mean that you cannot lose data - it is more about handling disk failure and giving high availability. It also makes more sense when you have a lot of data drives so backups are more of an issue because of the space required In your case with so few drives you could simply use one of the 8TB drives as a backup so the parity becomes less important.

It is worth emphasising that /mnt/user/system is the aggregate of any /mnt/diskX/system locations so the first 2 are just different views of the same folder.

2 x parity for 1 data drive is horrible overkill for the number of drives - particularly if you have decent backups. It tends to be more common to consider a second parity drive when you get up to something like 8-10 data drives. In fact with good backups I would consider going the other way and running without any parity at all as that gives better performance.

I don’t see how option 3 is possible as you only have 3 slots Option #2 looks possible and the old 2TB disk could then perhaps be plugged into an external USB box to give you space to be used for backups, or other uses?

You should provide your system’s diagnostics zip file (obtained via Tools -> Diagnostics) attached to your next post in this thread so we can see what is going on. you should be able to recreate your dockers with their settings intact without problems, but the fact you got this issue in the first place suggests there may well be something else going on.

Have you checked exactly which drive the file is going to? It is possible there is not enough space on the drive chosen to actually hold the file. Once a drive has been selected for a file unRaid will not switch it to another one so you can get the file transfer failing when the drive runs out of free space.

Why is your cache getting that full in the first place? Since you can always write to the cache much faster than the mover can transfer files to the array you should really have enough space on the cache to handle a day or so worth of files. Running it hourly may not help if you are putting too much on the cache. Mover is really designed to be run less frequently in an idle period (e.g. overnight). Having said that since I do not know the details of your Use Case maybe an hourly schedule will be appropriate.

If you go into the Advanced view on the Docker tab you can: re-order the start up order set delays after one docker container is started before attempting to start another one Using this might allow to use values that mean you do not encounter this issue. another possibility would be to use the User Scripts plugin to run a script after array start to automatically restart any docker that needs it.