itimpi

Difficult to tell without more information! The fact the disk gets disabled means that a write to it failed but that could be for a wide variety of reasons. I would suggest that you use the Tools->Diagnostics option and post the resulting zip file.

I would assume that the post-read for a cycle also acts as the pre-read for the next one?

I have noticed that I only seem to be able to click on a drive in the Unassigned Devices tab to get its SMART attibutes if I first mount it. Is there any reason why I cannot get them for drives that are not mounted?

Great idea, but can I suggest that you change the message slightly to say that the unRAID server should be whitelisted rather than the specific page? Also if feedback suggests this is working well maybe it should be made a popup so it is more 'in-your-face and harder to ignore?

Worth pointing out that you can set over-rides for individual disks by going to the settings for that disk (in case you also missed those )

No need to set anything. Since preclear wipes any existing file system anyway it does not matter what is currently on the drive.

Are you sure? I cannot see any such setting.

Lovely, it's good to know there is such an option in SMB, that would probably resolve the IP camera issue. Still, I think it would be very nice to also be able to do some kind of IMG shares, as a quick and painless implementation of quotas for external users... One problem I would see with the img approach would be that the full space for the maximum quota for each user would need to be allocated up front. Something more dynamic would seem desirable unless you expect each user to use up their full quota.

I was moving files from one disk to another today (using rsync) with the service enabled. I started getting lots of error messages on the directly attached monitor acting as a console (but not in the syslog) about sha256sum being unable to stat each temporary file that rsync creates while doing a transfer. I presume this was because rsync had renamed the file to its final name having completed the transfer so sha256sum could no longer find the file it was looking for. Is this to be expected? I disabled the service and that stopped the messages but thought I should report it in case it point some other deeper underlying issue. It would seem that it would be a good idea to suppress this type of error message to avoid cluttering up the console output (perhaps by redirecting it to /dev/null), but I guess this could have some undesirable side-effects for other types of errors?

I think that drive has problems. The Pending Sector count needs to be 0 for the drive to be used successfully with unRAID and that SMART report for the drive shows 1453 (it has probably gone up since). That is probably why the count shown is incrementing so slowly - the drive is continually retrying to read sectors, and eventually giving up and marking them as 'pending' to indicate a read failure. I bet if you looked at the syslog it will be filled with read errors for that drive.

In theory you can start again with the post-read, but that leaves open the question of why it failed in the first place! Things to do before trying again would be:Run the tools->Diagnostics option in case it has any information relating to why the preclear failed. You could post the ZIP file here if you want anyone else to look at it. See if you can obtain a SMART report for the drive (there should be a copy in the diagnostics file but doing it for just this drive will see if it may have dropped offline. Also the SMART report might indicate if the drive is having problems. Look in the preclear reports to see if there is anything useful about the earlier stages. Check cabling to the drive

The process seems to be CPU bound so you probably do not want to run more parallel tasks than you have cores in your machine. Certainly I see that as soon as I increase the number of parallel tasks above the number of cores I have the ETA for all the tasks starts getting longer.

I've previously requested ata info here. Unfortunately, it's not invariant, it can change as much as the sdX assignments. However, in a small system with few controllers it can be consistent enough to appear invariant. The more controllers you have, the more the order of loading them can be different. I had always thought the ata values were invariant, bit if they are not then I would have thought there was even more reason for the plugin to display them automatically.

Correct. As long as the drives were previously used by unRAID then after a New Config they can be assigned again and the data remains intact.

I was wondering whether there was any way to get this plugin to automatically show the ataX type numbers associated with a drive as many kernel error messages refer to a drive in this way? If not then I guess I can go through adding the information manually, but I thought that it would be better if the plugin derived it automatically so that it followed any drive being physically moved in the machine. It could then be displayed as part of the device information.e.g. Device: sdX (ataY). The ata type information is useful as it relates directly to the physical port that a drive is plugged into and is invariant across boots (unlike the sdX information that can change).

I would be very surprised if SNAP works correctly on the 6.1.x series of unRAID releases as I do not think it was updated to take account of the changes to the security model. However I have not tried it myself so I could be wrong.

I see no reason why the relevant drivers could not be loaded at the time that the system is started up in the same way that plugins are initialised at that point. The flash drive remains mounted regardless of whether the array is started or not so that is not an issue. I run my VMs from a drive that is not under unRAID control so that is probably all that I personally would need. I would be quite happy to start/stop some VMs via the go/stop files. There may be a significant number of users who would be happy with just this level of support for running VMs independently of the array. Having said that a way to keep the cache drive mounted when the array is stopped would be good. However doing that would mean that GUI support would have to be added for explicitly mounting/unmounting the cache drive for the few occasions where that is needed. I can also see complications arising in cases where a specific users VMs have a dependency on array drives being available. There would also have to be general enhancements around starting/stopping VMs via the GUI.

Not that I am against this being released as a plugin, but surely if you had it as a docker with /mnt internally mapped to /mnt externally (and possibly a mapping for /boot) you would have full access to all the physical media? Having said that since it is basically a script it does not have the sort of dependency issues that are the main reason for NOT installing some apps as a plugin. It therefore does not put system stability at risk.

What format are the disks? Recently a warning was added that problems might be encountered with the plugin if Reiserfs is being used for the disks.

Just in case it might help the limit applies to devices attached to the PC regardless of whether they are being used by unRAID or not. Having said that the if you sent off the email as suggested Limetech are normally good at getting back to you quickly.

I see this as well! I wonder if it is better to simply remove these from the list of tasks rather than try and work out how to mark them as completed rather than aborted? The intend is to show the final result and it stays there as long as you don't leave the page. Once going to another page and do a revisit then anything completed isn't shown anymore. I just checked with the latest update and it does seem to be fixed. The behaviour is now exactly what I wanted.

I see this as well! I wonder if it is better to simply remove these from the list of tasks rather than try and work out how to mark them as completed rather than aborted?

I do not think a laptop is going to be any good in this role. KVM does not work with integrated graphics (at the moment at least) and there needs to be a GPU that is available for unRAID purposes (typically the integrated GPU is used for this) even though unRAID itself can be run headless. Also once you have passed a GPU to a VM then that GPU is not available for either another VM or unRAID until the VM is closed down. You can RDP from one VM to another one but that does not sound like what you are looking for..

no. This is an alternative approach and only provides file integrity checking via checksumming (it has no recovery capability). It also stores the checksum information within the file system metadata so you do not see separate checksum files on the system.