itimpi

Any more details on the exact error message (perhaps a screenshot might help).

Assuming that you mean a disk already in the Unraid array, not unless you have software on your PC that can read the Linux file system (probably XFS which is the default for array disks). Having said that you could consider booting the PC off a Linux ‘Live’ dvd and use that to copy the files onto the dtive as that would understand the XFS file system format. If going this route it is important that the disk is partitioned and formatted on the Unraid system to ensure it conforms to what Unraid expects. After moving the drive back to Unraid you would have to rebuild parity (if you have a parity drive). As was mentioned if you have a removable drive then it can be plugged into the Unraid server and mounted using the Unassigned Devices plugin (which supports all common PC/Mac file formats in addition to Linux ones).

Turbo Mode is what is described here in the online documentation that can be accessed via the Manual link at the bottom of the GUI. Getting to get decent speeds over WiFi is very unlikely to happen.

You did not define what you meant by ‘slow’ on this context You also did not specify what you had for the USD Cache setting for this share. Plugging a drive into the server and mounting it via the Unassigned Devices plugin is the commonest (and normally fastest) way to transfer large amounts of data. Doing it over the network is almost invariably slower but can be more convenient.

I would not think you want the SSD added to the array as you cannot get decent speed in the array as writes are slowed down by the need to update parity in real time. I would think instead that you want the SSD in a pool as that does not suffer the same performance impact. Having said that in your case you would need to physically move the folder corresponding to the share between the two drives to achieve what you want.

It should not make any difference, but perhaps if the system is heavily loaded something like power supply loading might be more of an issue.

This. Once a disk is disabled (whatever the reason) then there are writes to it that have been lost so it is probably out-of-step with parity. The user therefore has to rebuild the disk to not lose such writes, or decide they can be lost and go via the New Config tool to accept the physical drive and rebuild parity instead to match the drive.

In Maintenance mode the drives are not mounted - this only happens in Normal mode. There is a version of memtest86 you can select from the Unraid boot menu if you boot in legacy mode. if you use UEFI boot mode or have ECC RAM then you should download the latest version from memtest86.com.

If you ARE going to try and reproduce this issue can you first enable the Testing logging mode in the plugin so I have more information on what is happening under the covers. The message is from the plugin (not Unraid) and indicates that the plugin THOUGHT an unclean shutdown occurred and that Unraid is about to start an automatic check. However if Unraid does not agree it was an unclean shutdown then no check is started. Looking at the code that can explain why the message text was a little strange. I am working on handling such a scenario in a tidy manner.

If you want to use a trial then you must not copy the config/super.dat file across and then reassign the drives as they were. Other configuration fines CAN be copied

You could always temporarily use a trial licence

Probably means it has failed

Are you sure that you had an unclean shutdown as the plugin should never prevent Unraid starting a parity check so something else is going on. Simply doing the reboot after an upgrade should not cause an unclean shutdown unless the Unraid did not succeed in stopping the array cleanly. it looks as if the plugin was expecting an automatic check because of an unclean shutdown and is trying to inform you of this. However the message itself does not actually make sense as an automatic check does not appear to have started, so I need to look into that code to see why the plugin thought an unclean shutdown occurred in case it got that wrong It has never been tested against rc5 so that may have caused some unexpected. behaviour and a spurious message to be displayed. Now that I can get rc5 for myself I will look into this.

The difference is described in this section of the online documentation that can be accessed via the Manual link at the bottom of the GUI

Not sure where you would have seen this information. Pending Sectors can only be cleared by the system trying to rewrite the problem sector so that is either successfully written or reallocated to use one of the pool of spare sectors on the drive. Adding a parity drive would only try to read the pending sectors so would not clear them. what you might have seen was that if you already have a parity drive with its contents valid, then on a read failure caused by the pending sector then Unraid can use the corresponding sector on the parity drive in conjunction with the corresponding sector from all other drives to work out what should have been on the sector that failed to read and will try to rewrite it. If that succeeds then Unraid will simply continue, but if that rewrite of the sector fails Unraid will disable the drive and stop using it and start emulating its contents using the combination of all other drives plus the parity drive.

Parity is always updates in real time which is one of the reasons having parity drives slows down write performance. The scheduled parity check is basically a housekeeping task to confirm that parity DOES agree with the current data drives as if it ever gets out of sync for any reason it compromises any future failure of a drive. Scheduling it weekly seems excessive, monthly or quarterly are much more frequently used.

The pop up you would have got when you ticked the format box would have explicitly told you that was going to happen. Having said that I understand that in a panic people have been known to blindly click the OK option without carefully reading the warning message, so making it even harder to ignore makes sense.

The issue is that adding a card can change the id’s. You should be able to undo the current passed-through devices, add the 10g card, and then redo the pass-throughs with the id’s that they now have.

If you only have parity1 then you can do that as parity1 does not include the slot number in its calculations. However if you have parity2 then you have to rebuild parity as the parity2 calculation includes the slot number as one of its inputs so changing slot numbers invalidates parity2.

Just a warning those are unofficial (I.e. old) pages for those steps. The current ones can be accessed via the `Manual’ link at the bottom of the Unraid GUI that takes you to the official documentation. I do not think there is any significant difference but it is always better to use the latest versions.

Yes - but if we can make it even more proof against users taking the wrong action through not properly reading (or understanding) the pop up it would be a desirable change. I must be honest and I do not see a really good reason as to why an emulated drive ever needs to be formatted, but the difficulty is in how to stop it (or at least make it harder than it is).

This sounds like it might be a good idea. This would not be trivial to implement though, but I might see if I can work out a Pull Request that implements this in a way that it could be done as an alternative popup to the one that is currently given when you elect to format a drive? I wonder, however, if anyone can come up with a Use Case for when it WOULD make sense to allow formatting of an emulated drive? There is frequently a need to do this as it is not the disk that caused the drive to be disabled but the something else so not such a good idea. I also think this would be much harder to detect in a sensible manner.

Does seem like it could be Dolphin. You could try accessing a share set to Public (most of yours seem to be set to Private) so no authentication is required to see if that works

I think you have to copy/paste it into a new script entry within the User Scripts plugin.

You are likely to get better informed feedback if you post your Unraid system's diagnostics zip file so we can see how you have your shares setup at the Unraid level.