itimpi

Unraid checks the disks in ascending order. Therefore if a lower numbered disk is allowed to be part of the share and has enough space and meets the Allocation Method and Split Level criteria that is where it is sent. I believe this is the behaviour that you want to change with a new Allocation Method setting? I think you want it to always first check any disk that already has the path for the file rather than simply in ascending order?

It is important to realize that the size of a file is not taken into consideration when choosing a disk. If the disk satisfies the Minimum Free Space criteria it can be chosen and the system start writing the file to the disk. If the file does not fit you will subsequently get an error as the free space is exhausted.

Rerun the xfs_repair without the -n (no-modify) flag and the drive should mount fine once it has finished. regarding you original issue if the drive had shown with the same serial number when being moved from the USB enclosure to the internal connection Unraid would have just picked it up fine. However it appears that the drive was reported differently when in the USB enclosure compared to when it was directly attached which is why Unraid did not realise it was the same drive.

Not quite sure what you are asking? Mover will not auto-start if interrupted, but the next time it does its scheduled/manual run it will continue from where it was 9n terms of moving files.

The vast majority of the time this means that there is File System corruption on the drive that can be fixed by Clicking on the drive on the Main tab and using the option on the resulting dialog to check/repair the file system.

The chances are the drive just has file system corruption. To fix this click on the drive on the Main tab and that will take you to the dialog from which you can run a file system check and/or repair. If not sure how to interpret the output then come back and post it and ask for help.

Disabling IOMMU means that you cannot run VMs with hardware pass-through. You can still run VMs that do not need hardware pass-through. Marvel controllers also seem to be prone to dropping disks offline for no discernible reason. The issue seems to be a compatibility issue between the Marvel drivers and the latest Linux kernels. The fix (if one is possible) is outside Limetech's control. If you want to run VM's with hardware pass-through then the easiest thing to do is to stop using the Marvel controller and switch to using a LSI based one which work fine with current Linux kernels.

Yes. Appdata backups are normally to the array (in case there is a problem with the cache drive). Check what you have set for the target? If it is to the array then it will no longer be possible to rebuild disk2 and you should rebuild parity to make sure it matches your current drive assignments in case another drive has issues (I suspect that the moment it does not) Can the drive be mounted when it is shown as an Unassigned device?

it sounds as if you did not start the array with disk2 assigned and then stop it to unassign the disk and restart the array? That would have left you with disk2 being emulated. If you did the unassignment without that initial start then it would not be emulated (and parity would be invalid). Has anything been written to the array in the meantime? Have you tried to rebuild parity?

Your syslog shows that you are getting continual resets every few seconds on ata10 which is drive serial ST10000VN0004-1ZD101, ZA2AQFFD which is why the rebuild is going so slowly. i would suggest you stop the rebuild and carefully check the SATA and power cabling to this drive which is the commonest cause of such issues, and then restart the rebuild. You had probably disturbed the cabling when putting in the replacement drive.

This is a very common Use case. You set your SSD to be the cache drive. The commonest use for the cache drive is as an ‘application’ drive for when performance is important. You can also use SSD’s as an Unassigned device if you do not want it to be part of the cache.

If disk2 is not being emulated then it’s data is not recoverable by simply rebuilding onto a new disk. without knowing exactly what steps you have already taken to get your array operable on the other drives it is impossible to determine if there is any path forward that might lead to the contents of disk2 being recoverable or if you have already made this impossible.

I assume that you have other data drives and parity drive(s)? If so you cannot simply remove drives as this invalidates parity. There seem to me to be two basic approaches you can take: Follow the procedure for replacing a ‘failed’ drive for each drive in turn. This is time consuming but will keep your array protected throughout. Use Tools->New Config to allow all drives to be replaced at the same time. This will invalidate parity so until parity has been rebuilt with the new drive set the array is unprotected.

It Is possible for Docker containers to access devices on the local LAN. It depends on how you have set up the networking for the container. You need to give some information on how you have the container set up for anyone to be able to spot what may be going wrong.

I suspect that you may already have slightly over-committed the available space due to the fact that the SSD size will be using decimal units (where K = 1000) and the size you set for the vdisk is binary units (where K = 1024). When using vdisks a little spare space is always a good idea as you can start getting strange errors in a VM if all available space on the underlying file system is used.

Reading FROM the array is always going to be limited to the speed of the disk you are reading from since Unraid does not use striping. However any modern disk should be fast enough to saturate a 1 Gps network without problems. It is only if you have 10 Gps networking that the network will not be the limiting factor.

When you have things set up do not forget to make a backup of the flash drive by clicking on it on the main tab. It is a good idea to do this any time you make a significant configuration change

You should post your diagnostics zip file (Tools -> Diagnostics) when this occurs to see if anyone can spot the likely cause.

If you want really good graphics performance then you should use a monitor directly attached to the passed-through GPU as you will never get anything close to bare-metal when accessing it remotely. Also the browser based VNC client included with Unraid does not support round. Having said that you can get far better graphics performance remotely by using a different client installed into the VM. Many people use something like Remote Desktop but my personal favourite from both a performance and capabilities perspective is NoMachine which is free for personal use (NoMachine also supports sound).

Not me either - I assume the file is corrupt? From the size shown it does look smaller than I would expect.

Chances are that Nextcloud has a location where it uploads files to before moving the file to its final location. If that is the case and that location has not been mapped externally then that would explain what you are seeing.

When a disk is disabled then if run properly the data that is on the rebuilt disk will be the same as you can see on the emulated drive (while the disk is disabled) before doing the rebuild. A mistake that many people make is to at some time to do a format from the GUI thinking this is a good idea not realising that effectively wipes the data from the emulated drive and updates parity accordingly so you end up rebuilding a disk with no files on it. The 6.8.0 RC series has had a more prominent alert added to try and reduce the instance of such mistakes - we do not yet know how effective that will prove to be.

I suspect you could still do a manual upgrade even with a USB drive that small If replacing it then remember that USB2 drives tend to be more reliable during the boot process than USB3 ones (and slightly cheaper). I am currently using a 16GB Sandisk Cruzer Fit and a 16GB Kingston Data Traveller without problems although some people seem to think that the very small form factor drives (i.e. Cruzer Fit) can be more prone to heat related issuesi

That could easily have that effect as a write to any drive will require all disks to be spinning.

There is a known issue with the 6.7.2 release that can cause this type of problem. The issue appears to be fixed in the 6.8.0 RC series (currently up to RC7) so you might want to consider trying that release.