itimpi

You may find this link describing the boot process to be of interest. If there is no /boot showing In the ‘df’ command then stage 4 has not completed successfully.

The error will persist until you click on the orange icon on the dashboard to acknowledge the error. You will then only be alerted again if that SNART attribute changes.

The parity swap procedure should work, so I wonder if you got all the steps right. i do not see much point in adding the 8TB as parity with a bad drive present. I would be tempted to remove it, start the array to commit its removal. At this point you should see your bad disk as not present and it’s contents being emulated. You can now try the parity swap procedure again and come back here immediately with new diagnostics if it does not work so we get a chance to see what happened.

You should be able to straight to 6.8.3 bypassing 6.5.3. You can copy the bz* files over SMB. the main things to check are: you do not have any 32-bit packages being installed via the ‘extras’ folder revert your go file to the version from the zip remove any plugins you used with v5.

If you log into the console (username root) and issue the 'df' command does it show that you have something mounted at /boot?

It is not the loading the drivers that is an issue, but generating them in the first place A secondary issue is that Unraid tends to be on the latest Linux kernels, and Limetech have frequently mentioned that they have trouble getting drivers to even build against the latest kernels. The hardware manufacturers tend to concentrate on their Windows drivers and so the Linux drivers are second-rate citizens in terms of getting updates for new kernels.

The issue is still there, but the issue is about mixing disk and user shares in the SAME copy/move command.

Unraid runs from RAM so including all the development tools required to support compiling drivers would significantly increase the footprint.

It is possible that the drive itself has remembered the new setting. You probably need to go through a power cycle sequence to see if it sticks in such a case.

The problem with what you did was the change was only in RAM so did not survive a reboot. Unraid runs from RAM so when you reboot you get a fresh copy of Unraid unpacked from the archive on the flash drive and loaded into RAM. The easiest way to do run a script that survives a reboot is be to install the User Scripts plugin and use that to run the script.

To be honest those speeds look quite reasonable. Do not forget the disk speed is being measured in bytes while things like network speed are measured in bits. I often assume as a rule of thumb about a 10-1 ratio allowing for overheads.

That makes sense as the binding would hide the card from the Unraid Linux level It does sound as if might affect your ability to use the card in a VM

If you are passing the card through to a VM why do you need the Nvidia build in the first place as it is the drivers in the VM that control the card. I thought the main use case for the Nvidia build was to be able to use hardware transcoding in docker containers? Your description of your symptoms suggest that the card is not properly resetting when closing down the VM and it takes a power cycle to achieve that.

The diagnostics cover the reboot period so I would guess the syslog server is already enabled. I could not spot anything obvious in the syslog that might be the cause of the reboot.

You need a step 3.5 where you Unassign any disks that you no longer want to be in the array before starting the array to commit the revised drive list and initiate a parity sync using the remaining disks.

If the disk has not been used by Unraid before and is showing as Unmountable in the GUI then you need to format it to create an initial empty file system on it.

A simple workaround is to put the flash drive into a PC/Mac and copy its contents to a local drive.

It is worth remembering that USB2 drives seem to be more resilient (as well as being cheaper)

In principle if your disk controller can see and handle the 12TB drives correctly it should have no problems handling 16TB drives as well. Having said that I am not sure that I have seen any forum posts where a user has started using 16TB drives. My suspicion is that this is because the cost/TB is not yet favourable to 16TB drives and Unraid users tend to be a little cost conscious. Bear in mind that no data disk can be larger than a parity drive so you would first have to move parity to using 16TB drives. One thing to be aware of is that the time for operations such as parity checks is going to increase by a third as the time is determined primarily by the size of the largest parity drive.

In principle yes, but there are some points you should note: make sure you remove your licence key file from his copy of the USB stick or you will get your licence blacklisted when he gets his licence. the disk assignments will need to be completely redone as obviously his disk will have different serial numbers. This can be done via Tools >> New Config. If you are running VMs with hardware pass through then their configuration will not be valid on different hardware there may be some other points I have missed but you get the gist. having said all that since configuring Unraid can be done very quickly why bother? You could start on his system with a brand new setup and apply configuration changes using yours as a reference.

if you have a 'downloads' share and it is not showing up there then it is not in that location on either the array or the cache. You should provide your system diagnostics zip file (obtained via Tools >> Diagnostics) attached to your NEXT post to allow us to get a better view of how you have your system set up.

No, it should not be necessary to have the array started to access the GUI.

The share name (Public) counts as level 1 so Full is at level 4 not level 3.

You probably want to install the Dynamix SSD Trim plugin to get this done at regular intervals.

The diagnostics show that at the Linux level /dev/sda1 is still mounted at /boot as expected so it is not at all clear why sdg should be displayed in the GUI. Did you set a name for /dev/sdg in Unassigned Devices that may be confusing the GUI?