itimpi

This solution would require the controlr author to be providing a server which the current solution does not (unless I have misunderstood what you are asking for). If a server is required how do you know it is secure? The moment you let ANYTHING from the internet into your LAN there is a potential security risk, but I think the open VPN is one of the lowest risk options, particularly if you set it up to require a certificate to use it at the client end

Just for future reference it is easier to attach the zip file rather than extracting the Individual files.

Have you tried typing \\ip_address into Windows Explorer. That would show if this is a problem about this PC agreeing with unRAID about which machine is acting as the Local Master at the netbios Level.

That probably means that the ‘cp’ command is not located in /bin inside the container. You could try omitting the /bin part to use the search path, or instead try using /user/bin in case that is where it is located.

The leading ‘.’ on the commands will make them relative to a home folder. For ‘cp’ this will not work as you need an absolute path to the binary.

I have the Openvpn-as docker installed on my unRAID server and my iPad set up with the openVPN client configured with a connection profile to the unRAID server. If I want to use ControlR away from home I simple start the openVPn client on my iPad (which only takes a few seconds) to open the VPN connection to my unRAID server, and then launch ControlR which now functions exactly as it does when my iPad is connected to my local LAN.

It works fine for me! Allows me to access everything I can when connected directly by WiFi to my local LAn. Not surprising as the whole point of such a setup is to give you secure remote access to your LAN. the VPN Client on the router should not conflict as that would only be used for outbound connections. Having said that I do not have such a client on my setup so cannot be completely definitive about it.

The ‘df’ command shows that the USB stick has not been mounted. There should be an entry for /boot (typically with device /dev/sda1). Quite why this is happening I am not sure as you seem to have checked for the obvious culprits. you could try manually mounting the USB stick as /boot and then re-running the diagnostics to get the zip file that may give those perusing this thread some idea of what is going wrong.

This suggests that the flash drive has not been mounted as /boot (so the diagnostics file was only saved to RAM). The USB stick not mounting would also explain why you have no GUI. You could check this using the ‘df’ command to see if the /boot mount point is present and pointing to the USB stick. You should check that the USB stick is labelled as ‘UNRAID’. Assuming that is not the problem then it is worth trying the USB stick in another port (preferably a USB 2 one as USB 3 ones often seem to cause problems).

UnRAID will not stop you from assigning SSDs as Array drives. They are not officially supported because of potential issues with the way they might interact with Trim potentially invalidating Parity (depending on how a particular model of SSD handles Trim operations). If you are running without a Parity disk this is not relevant. There have also been tests done by existing unRAID users with SSD based arrays and they seem to work fine for the SSD models they were testing at the time.

You can simply set the array up with a single data drive and no parity drive to get that functionality. If you later decide to set up data drives then you can move the SSD to be a cache drive at that point.

unRAID has no support for this. The closest you would get is to use a hardware RAID controller to provide the RAID1 capability - and let unRAID treat it as a single drive.

How often you run a parity check is really up to you. In theory parity checks are completely optional, but they are seen as a way of getting early visibility of potential problems. in terms of elapsed time it is the size of the largest parity drive that is the key determinant of the time it will take - not whether you have dual or single parity.

It probably will, but I wonder if it is better to do the resize before starting emhttp?

Looks like your syslog is getting spammed by error messages relating to a (I assume non-existent) floppy disk drive. Have you made sure that floppy disk support is disabled in your BIOS settings? if you want to make a change to the syslog size persist across reboots then you need to add the command required to the ‘go’ file in the config folder on the flash drive.

Have you given the script execute permission? If you downloaded it to the flash drive this should be automatic (because it is FAT32 format) but will not be the case if put elsewhere. Alternatively run it using the ‘sh’ command which does not require the script to have ‘execute’ permission.

You will want to make sure that this location is excluded from being cached then.

it can be but as long as you do not use one of the icon based views when accessing unRAID it tends to behave OK.

At the moment the Edit option for a VM does not allow you to specify the port to be used VNC, but always sets it to 'auto'. If you manually use the Edit XML option to set the port to a specific value then when you save the settings the GUI is quite happy to correctly display the port you have just set. The problem is that if you now use the Edit option then it is reset back to the 'auto' setting. What I would like to see is the VM Edit option bringing forward the current setting, and allow you to set it to either auto or to a specific port.

I can see that it will not show up under the unRAID Share browser as that is specific to shares on the main array and is not aware of shares mounted from outside the unRAID server. When trying via docker - where are you looking for the share to appear? With a docker you are likely to be looking at the raw Linux level, not the network share level. At the Linux level they will appear under /mnt/disks

That message means you have a browser window open from before the last time you rebooted unRAID.

It is quite normal to have issues stopping anything that requires a disk sync if you have a pre-clear running in parallel. The pre-clear keeps writing new data so that the sync never completes. Another symptom that is common in this scenario is being unable to stop the array for the same reason. The only solution is to either wait for the pre-clear to finish or to terminate it early. In a perfect world it would be possible to pause a pre-clear and later resume it, but I can understand that this would add a very large level of complexity to the plugin and hitting this issue on a running system is rare enough that it almost certainly does not justify the effort that would be required.

You can set the Global settings to be what you want for the external drives, and then set the array drives to what you want for array drives. That might give you the setup you want.

I do not think you can easily do exactly what you asked. However you can over-ride the global settings for any of the array drives by clicking on it in the Main tab and setting a custom temperature just for that drive.

If you have the Pro license then only drives assigned to unRAID count. For the Basic and Plus licenses ALL directly connected drives count whether they are assigned to unRAID or not. the check is applied at array start time so a drive plugged in later (e.g. a USB drive to be used for backups) does not count. if the question related to mounting a drive on another system via SMB then that does NOT count.