itimpi

Strange. That does not even go over the real network. I assume the files on the boot disk and USB stick are a vanilla unRAID release so there is nothing already configured that might mess things up. Did you try setting the virtual NIC to exactly the same one I had in case it matters somehow? That seems a bit desperate, but I am running out of ideas on what might be going wrong. Just had a thought - have you checked the USB stick ends up mounted as /boot. If not it might not be in the correct format (FAT32) which has been known to have strange side-effects.

I think in this context it may be the IP address of the machine trying to access 192.168.1.12. Quite why it should think it is unreadable when it is on the same subnet (assuming you have the typical subnet mask of 255.255.255.0) is not clear - sounds like there may be a networking issue at the host (perhaps a reboot will clear it).

I cannot see anything obviously wrong! I have unRAID running without issue under VirtualBox and am not experiencing the issue you seem to have encountered. My VM settings are shown on the attached screenshot. The only differences I can see are that I have defined SATA disks instead of IDE, and that I am actually using a slightly different NIC for the bridged adaptor - but I would not have thought either of those should really matter. You do not mention what version of unRAID you are intending to try? If it is the new 6.2 beta which now includes a built-in GUI option then you can bring that up by editing the syslinux.cfg file on the boot device (I assume a VMDK) and moving the Default entry to the one to load the GUI. Editing the syslinux.cfg on the USB flash drive will not have the same effect (since VirtualBox does not supporting from USB then I assume you have this plugged in separately and passed through to the VM). This is the same GUI that you would get by connecting from outside the VM via a browser.

what is the point in leaving a dead drive in the array. Once you get any write errors to a drive unRAID will stop writing to it so no point in keeping it in the array. You also increase the chance of encountering a multiple drive failure scenario which will lead to data loss. . I meant keeping it in till it dies. As in reallocated sectors could go into the 100's and you'd still keep running with it. my experience is that if the reallocated sectors keeps growing then the drive is likely to fail. There is nothing intrinsically wrong with having a significant number of reallocated sectors as long as the number stays relatively stable. It is regular increases which are a sign of trouble. As has been mentioned of far more importance is the value for pending sectors as any non-zero value means you may not be able to recover a different disk that fails without some level of data corruption

what is the point in leaving a dead drive in the array. Once you get any write errors to a drive unRAID will stop writing to it so no point in keeping it in the array. You also increase the chance of encountering a multiple drive failure scenario which will lead to data loss.

There is nothing wrong with having a reallocated sector as long as the value remains constant. Modern drives are designed to reallocate sectors if one fails. If it keeps increasing then the drive needs replacing.

what format does it give for the cache disk though? If your test changed it maybe you need to explicitly set it back to what it should be?

bitrot (I.e. Corruption not detected by the hardware) seems to be exceedingly rare, and it is only in the last few years that systems capable of detecting it have started to become mainstream. Much more likely would be hardware errors such as a failure reading a sector and unRAID does protect against those errors. Bitrot does not mean a file cannot be read - merely that the contents are not what they should be and you are not automatically warned this is the case when you open the file. For media type files (which I think is one of the main uses for unRAID) it is quite likely that the corruption may not even be noticeable. For other file types (e.g documents) the corruption would almost certainly be noticed as garbage would be displayed.

I wonder if the issue is that you simply do not have enough RAM to keep all your directory information in RAM?

I agree with you. Perhaps the simpler solution will be to make the Control page the default rather than having to set an option? I wonder if any others have a view on this?

I like the simplicity of Up 1 and Down 2. These are in some ways cosmetic points, but getting them right makes the reports easier to digest and look for anomalies.

I would suggest leaving it blank for unchanged. Would make it more obvious exactly which values should be examined further. Also then you do not need to actually say it has changed - just include the details.

As far as I know you cannot - you have to do it at the command line level. However it only takes seconds to create the export file that can be viewed in any text editor.

Yes. you do not delete the appdata share after doing the move. What you do is delete the appdata folder of each array disk.

It is not that easy to view the attributes directly from Windows. However the plugin includes an export feature to write the checksums out to a text file (in the same format as used by some Windows utilises)

Looking at the time shown for the individual phases the 195 total must be for more than one cycle . The individual phase times are about what I see on my system with the 8TB drives so seem perfectly normal. With larger drives the elapsed time gain from the 'faster' preclear are quite significant.

You cannot run preclear against any drive that is assigned to the unRAID array. I assume that you currently have the drive in question assigned as parity?

I have found that if you do anything that will cause a Linux 'sync' command to be issued while preclearing (e.g. stopping the array, adding new disks to the array) then the 'sync' effectively last forever (I presume because the preclear is continually filling the Linux disk buffers so they never completely get flushed to disk). When the sync finishes (e.g. by stopping the preclears) then everything comes back to life). I am not sure there is a workaround for this - it is just an interaction at a low level between the Linux sync command and the disk activity currently taking place.

I believe it should if you have "Save new hashing results to flash" enabled. I don't. My reading of that option was that it wrote a new file including date in the name with the changes in it, not that it appended to the existing file. Could be wrong about that though.

Glad to hear that fixed it! Like many problems the fix is easy once the reall issue is identified

Are you certain that the USB stick was formatted as FAT32? If not then you can get these symptoms as the USB stick does not get correctly mounted, and therefore the command to start the GUI does not get executed. A quick check is to go into a console/telnet/ssh session and do the command ls /boot This should show the files/folders that were extracted from the ZIP download and placed on the USB stick. If it does not then the USB stick is not prepared correctly.

Yes, but is local ssh access to the unRAID server still working?

I have not tried it with the plugin, but I know using the preclear script you can clear USB drives. There are a couple of caveats: If it is USB 2 then it is very slow. USB 3 is similar in speed to SATA connected drives Many USB drives/enclosures do not report their SMART attributes. In such a case although the preclear will operate you get limited useful information from the preclear reports as it cannot tell you about changes to reallocated and pending sectors. Guess I need to dig out a USB drive and try it with the plugin to see if it is OK as well I think I can find USB enclosures that report SMART attributes and also one that does not to test both cases.

You can do it locally on the unRAID server using something like the 'mc' (Midnight Command) tool from a console/ssh session at the Linux command line level. There are also dockers that can be installed to provide a graphical method of file management locally to the unRAID server but I do not think most people bother with this extra complexity. Alternatively you can do it over the network using your normal desktop file manager on your PC/Mac as the Unassigned Devices plugin will expose the drive as a new share. However in this case you could just as easily have plugged the drive directly into the PC/Mac and copied it so not sure which you will find more convenient.

Yes - you never want anything in the root of the cache except folders that correspond to shares. The recommendation would be to have a folder under /mnt/cache/appdata corresponding to whatever application you are trying to install.