gfjardim

Unfortunately, I don't have a working ESXi instance to debug this.

Not without Joe L.'s permission. (author of preclear script). Not completely right (it's derived from the GPL'ed md driver), but I don't have plans to do it, since it's scheduled to be built in unRAID.

Not at all , Sparkly !

It's an additional container on my repository. Wow, I'm not sure how I missed this! I want to try it out, but I've been reviewing the code: https://github.com/gfjardim/docker-containers/tree/master/crashplan-desktop and it seems like it stores everything inside the Docker container? Would you considering setting it up a little more like the standard crashplan: https://github.com/gfjardim/docker-containers/blob/master/crashplan/config.sh so we don't have to adopt the account and re-synchronize every time the docker changes? That's just the GUI. There's no backup service running into it.

It's an additional container on my repository.

I have a working container with AirPrint and CloudPrint working, will update it and release something soon.

I've had the same issue. I disabled then re-enabled and got the apps working again. Haven't figured it out though. I think the Docker reloads the apps file structure and wipes out any changes made. When it does that the calendar and contacts directories in the apps directory are lost. Or you add your apps inside /var/www/owncloud/data/apps directory or you create a volume mapping pointing to /var/www/owncloud/apps ; either way I won't support it because involves messing with the config.php file, and I don't wan't to screw anyone's installation. By the way, updated to 8.0.3.

OK, found the root of the problem. Please do what's described in this topic, then send me the result of this command again: ls -la /dev/disk/by-id

no probs, just executed this but looks like no change.. should i restart array too? No need. Will have to investigate this further.

Made some changes, can you test them for me? Just run this command on your CLI and see if the disk appears: wget https://raw.githubusercontent.com/gfjardim/unRAID-plugins/master/source/unassigned.devices/usr/local/emhttp/plugins/unassigned.devices/include/lib.php -O /usr/local/emhttp/plugins/unassigned.devices/include/lib.php

Please send me the output o this command: ls -la /dev/disk/by-id

Thanks for reporting. Fixed and will be shipped with the next version.

jonp, I was thinking, this method of yours, the two step passthrough, is much safer than the simple passthrough without the pci-stub step. This could make passthrough of USB/SATA/Ethernet pretty much doable via the VM Manager plugin. Is Eric working on something like this on the present moment? PS: little code to find in which pci bus is unRAID's usb drive: udevadm info -q path -n /dev/disk/by-label/UNRAID |grep -Po '0000:\K\w{2}:\w{2}\.\w{1}'

I know that. This code only shows you which NIC is eth(n) and the PCI id. It's designed to gather info for your method, not to replace it. If, for an example, I wish to passthrough the unconnected NIC of my board, I can easily do so. It makes easier to pin a NIC to the physical port.

A easier method of discovering the right card to passthrough is running: #!/bin/bash for ETH in $(find /sys/devices/ -type d -iname "eth[0-9]"); do port=$(basename $ETH); export $(cat $ETH/device/uevent); link_status=$(cat $ETH/operstate); desc=$(lspci -d $PCI_ID| cut -d ':' -f3) pci_bus=$(echo $PCI_SLOT_NAME|sed -e 's#0000:##') echo -e "Found NIC: $port\n Name: $desc\n PCI id: $PCI_ID\n PCI bus: $pci_bus\n Status: $link_status\n" done

It's harmless. Perhaps put a check for file existence in front of the mv command and suppress the message ? I did, it was a typo.

It's harmless.

Ok, guys, talked to Tom and there are good and bad news. He agreed to delay the launch of VM and Docker to a latter stage of init, including a new event to be triggered by emhttp. This will allow users to mount disks before these services in an safer way. Again, thanks Tom for this. The bad news isn't so bad, specially when you hear Tom's reason. He didn't agreed to add init/shutdown events to emhttp, because "Doing this will break a key unRaid concept: that of 'started' and 'stopped'. The idea is that when 'stopped' it's ok to perform maintenance tasks on your storage devices because they are not mounted. " I do agree with him, so I won't support this kind of usage. PS: all conversation can be found here. .

Starting for today's update, array start/stop won't mount/unmount disks which "Auto mount" is disabled. If you want an always mounted disk, you can add something like this to the beginning of your /boot/config/go file: unassigned_mount /dev/disk/by-id/ata-INTEL_SSDSC2CT120A3_DISKSERIAL00000000000 This the easiest way I could manage with the events currently available. What about a always-on setting that is saved, and just a single command needed in the go file that would auto mount/share any multiple devices needed - less prone to a mistake in the go file for the mount to fail....? Thanks Myk I won't support this kind of stuff. I will ask Tom if he can put two more events in emhttp, one in it's init and one on it's shutdown. If he agrees, then I will add a boot option to Auto Mount, ok?

That's what it does. RobJ asked about an always mounted solution, and that is accomplished with mounting the disk before ehttp (webgui) does and set the Auto Mount to off.

Starting for today's update, array start/stop won't mount/unmount disks which "Auto mount" is disabled. If you want an always mounted disk, you can add something like this to the beginning of your /boot/config/go file: unassigned_mount /dev/disk/by-id/ata-INTEL_SSDSC2CT120A3_DISKSERIAL00000000000 This the easiest way I could manage with the events currently available.

Thanks, fixed.

That's it, that's what we have to trigger events. from my own syslog, startup: Stopping the array: This is the order emhttp triggers events. In bold, the triggers this plugin uses.

Sorry, accidentally private. Fixed.

This is problematic, since both uses the "disks_mounted" event to start, and it's almost certain that docker starts first due it's alphabetical precedency. But, since docker will fail if the image directory doesn't exist, a simple /etc/rc.d/rc.docker start in a script should suffice. I'll elaborate: Let's assume you mount a disk into e.g. /usr/disks/my_docker_disk and set your Docker image to /usr/disks/my_docker_disk/docker.img. In case Docker start first, it will fail, since there wouldn't be a /usr/disks/my_docker_disk directory, so you can start it later by writing a script. See the video above. It works for me, and I see no reason it wouldn't work for you.