itimpi

Fair enough - I get days like that as well I was just wondering if there was something profound that I had missed

What is the rationale for using Cache=No rather than Cache=Only once mover has completed?

Are you saying the 'reboot' command from terminal is now not working?

Have you tried booting in Safe Mode to eliminate all plugins from being the cause of your problem? The syslog seems to show that the array IS actually started!

You must NOT have a drive mounted if you are going to pass it through to a VM.

At the moment the UEFI boot menu is created by simply using an INCLUDE statement for the legacy boot one which is why they are identical. I have already done some testing with separating out the elements that should be common between the two boot modes into a separate file (which I provisionally called syslinux.inc) and that allows for different boot menus between the two modes. That made it it easy to only include the memtest boot entry in legacy boot mode. The changes to the GUI I mentioned would need to reflect this change. is the code for the boot menus available anywhere on gitHub that I could access? I could then work on the changes and create an appropriate Pull request. I know the GUI code is available there)

I cannot see any reason why not. You might need to try it to be absolutely certain, or get feedback here from someone else who has already tried it. Performance of NTFS is likely to be slightly lower but that is probably not the main criteria in this case? One thing to bear in mind with assigning UD mounted devices from docker containers is to make sure that when setting up the Container path mapping you use one of the “Slave” modes.

Starting it via the ‘go’ file is the way that emhttp is meant to be started. Is it possible you have changed that file incorrectly?

Probably better is this option that is available in current Unraid releases.

I do not think licensing allows for the UEFI free version to be added to a commercial product. Giving a different menu in UEFI mode definitely looks possible though. interestingly enough I have just been looking into seeing what would be involved in changing the boot menu for UEFI boot. It is not as trivial a change as it first appeared as it would also require GUI changes to take this into account. If this is done I would think it would also make sense for the menu title to mention the boot mode that was used?

Reboots are normally hardware related in some way. Do you have a UPS? If not then a short power cut could cause that to happen.

You might get away in the short term with my suggestion of using a USB flash drive to satisfy the Unraid requirement of having at least one array drive, and keep the 3TB drive in NTFS format as a UD device. Then when you get a new drive you can put that into the array and copy data from the NTFS drive onto the new array drive. Having done that the current NTFS drive could then be added as an additional array drive as at that point you do not mind the fact it’s contents will be lost as Unraid formats it.

All array drives in Unraid need to be formatted by Unraid so you cannot simply add the drive to the array. You could, however, easily mount it outside the array using the Unassigned Devices (UD) plugin. What is not clear to me is where you want to end up? For instance do you intend to continue to run Windows in a VM under Unraid? If so you may want to keep the SSD as a Windows boot drive mounted using UD. In such a case since having at least one array drive is mandatory in Unraid you could assign a second USB stick to this role if it is not going to be used to store data.

I would think this would be the easiest solution. Give the second instance a new name so they can be told apart.

You will get nothing like the raw disk speeds when writing to the parity protected array. By default speeds of 30-40MBps seem typical. You might find this description of the Unraid write modes of interest to explain why.

You should post your system diagnostics zip file (obtained via Tools >> Diagnostics) with your NEXT post so we can see what is going on.

On that basis it is worth pointing out that docker start order can be changed by dragging them into order on the Dockers tab. In advanced view you can also add a delay before starting the next docket

If many containers share the same base Linux images (which is very likely) then their space may well end up being counted multiple times. I would not have expected looking into the sub volumes directory to tell you anything useful. If you do not start any of the containers you are now downloading then you can use the option to calculate the container size as the initial start point.

If the usage of docker.img is growing then you have some path that is not mapped externally that should be. Have you tried clicking on the button to calculate the container size on the Docker tab? Doing that often makes it obvious which container is the problem.

Not quite sure what you are asking? The root user is the only one who can access the GUI. Other user accounts are only for share access.

Yes that is probably easiest. You are not really increasing the wear measurably on the SSD as a rename is only a single I/O operation that just updates a directory entry.

It looks like your parity disk is in bad shape as the following SMART attributes do not look good: 5 Reallocated_Sector_Ct 0x0033 195 195 140 Pre-fail Always - 175 196 Reallocated_Event_Count 0x0032 180 180 000 Old_age Always - 20 197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 65524 If you have notifications enabled I am surtrised that Unraid has not been telling you about these

The syslog shows that Unraid is getting a timeout attempting to contact a DHCP server! If your router is meant to be acting as the DHCP server then maybe you should try rebooting it?

Definitely a RAM problem Anything other than 0 errors when running the tests means you have a problem. Sometimes it is just a case of reseating the RAM modules. You could also try clocking them at a lower speed?

The diagnostics show that your cache is failing to mount which could explain both your docker and VM problems.