botez

I had the same exact symptoms when I tried with Xen and never did try with KVM. Is love to hear if anyone has a solution for this as well. Sent from my VS980 4G using Tapatalk

bkastner -- When I used nacat78's instructions previously, I got the docker container to work. Also, anyone using my transmission docker should delete it. It's not as good as the gfjardem transmission docker, so I would recommend staying away from it.

I'm wanting to edit a dockerfile that's used to create an image that I'm using. When you pull an image from the docker repo, does it include the dockerfile? I'm guessing that in order to build from a dockerfile I need to pull from the user's github first and then build from that source, but I wanted to check on that with the docker power users around here.

What issue were you exactly seeing? I've been using this build for a while without issues.

I saw others were using gfjardim/transmission container with success. However, when I start the container transmission does not start. The logs simply say: CRIT Supervisor running as root (no user in config file) Any ideas on this? I'm running it as: docker run -d -p 9091:9091 --name=transmission -v /mnt/cache/appdata/transmission:/config -v /mnt:/mnt -v /etc/localtime:/etc/localtime:ro gfjardim/transmission

This did the trick for me -- now I can do the vfio-bind. Thanks for the tip.

It's still there! Ah, found it. Donation made. Sent from my VS980 4G using Tapatalk

Thanks gfjardim! Changing the docker.cfg file did the trick and I can now access the Owncloud container via bridged mode. You took that donate button down too soon

No, but I do have a bridge setup in my unraid network settings from when I WAS using Xen. It's named "xenbr0". Is that going to cause an issue?

Hmm, I changed "--net=bridge" to "--net=host" and now I'm able to connect to the owncloud server. I had to do this with some docker containers, while others have worked fine in bridge mode. I'm not enough of a networking guru to quite understand why one works and the other doesn't, so I guess I'll have to go look into that further. Thanks for the help guys.

Haven't been able to run through the websetup yet, because when I go to http://tower:8000 I just get a "This Webpage is not Available" message. Does anyone have any other ideas on how I can troubleshoot this?

I'm getting similar errors to billington.mark above -- root@Tower:/mnt/cache/appdata/owncloud# docker logs owncloud *** Running /etc/my_init.d/00_regen_ssh_host_keys.sh... No SSH host key available. Generating one... Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Creating SSH2 ECDSA key; this may take some time ... Creating SSH2 ED25519 key; this may take some time ... invoke-rc.d: policy-rc.d denied execution of restart. *** Running /etc/my_init.d/config.sh... *** Running /etc/rc.local... *** Booting runit daemon... *** Runit started as PID 323 nginx: [emerg] BIO_new_file("/opt/server.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/opt/server.pem','r') error:200 6D080:BIO routines:BIO_new_file:no such file) I tried deleting the config directory and restarting, but I had no such luck. My command used to start this container was: docker run -d --name="owncloud" --net="bridge" -e SUBJECT="/C=USA/ST=OR/L=SALEM/O=ORG/OU=UNIT/CN=troy.duckdns.org" -p 8000:8000/tcp -v "/mnt/cache/appdata/owncloud":"/var/www/owncloud/data":rw -v "/etc/localtime":"/etc/localtime":ro gfjardim/owncloud

I just updated the docker to the latest Madsonic beta release.

ls -altr /dev/vfio/ total 0 drwxr-xr-x 2 root root 60 Jul 7 20:48 ./ crw-rw-rw- 1 root root 10, 196 Jul 7 20:48 vfio drwxr-xr-x 13 root root 3640 Jul 7 20:51 ../ lspci -knv http://pastebin.com/Gvw3nLsA ls -altr /sys/bus/pci/drivers/vfio-pci/ total 0 drwxr-xr-x 20 root root 0 Jul 8 09:22 ../ --w------- 1 root root 4096 Jul 8 09:22 unbind --w------- 1 root root 4096 Jul 8 09:22 uevent --w------- 1 root root 4096 Jul 8 09:22 remove_id --w------- 1 root root 4096 Jul 8 09:22 new_id lrwxrwxrwx 1 root root 0 Jul 8 09:22 module -> ../../../../module/vfio_pci/ --w------- 1 root root 4096 Jul 8 09:22 bind drwxr-xr-x 2 root root 0 Jul 8 09:22 ./ dmesg | grep IOMMU Intel-IOMMU: enabled dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020660462 ecap f0101a dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap d2008020660462 ecap f010da IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 IOMMU 0 0xfed90000: using Queued invalidation IOMMU 1 0xfed91000: using Queued invalidation IOMMU: Setting RMRR: IOMMU: Setting identity map for device 0000:00:02.0 [0x9f800000 - 0xaf9fffff] IOMMU: Setting identity map for device 0000:00:14.0 [0x9c0d2000 - 0x9c0defff] IOMMU: Setting identity map for device 0000:00:1a.0 [0x9c0d2000 - 0x9c0defff] IOMMU: Setting identity map for device 0000:00:1d.0 [0x9c0d2000 - 0x9c0defff] IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]

Peter -- I'm trying to follow along on this, but I'm getting the following when I use your vfio-bind script. vfio-bind 0000:01:00.0 0000:01:00.1 ./vfio-bind: line 11: /sys/bus/pci/drivers/vfio-pci/new_id: Read-only file system ./vfio-bind: line 11: /sys/bus/pci/drivers/vfio-pci/new_id: Read-only file system Any ideas on what's going on. I ran checkdisk on the USB stick and it came back fine. Troy