Bungy

Try to remove the https directory mapping. That mapping is only required if you're providing your own certs (which is highly highly recommended)

AAron, He's definitely correct. You need to provide your own ssl certificates if you use the https mapping. Otherwise, you can exclude the mapping and it'll generate the certificates itself. I provide my own ssl certificates because it is linked to my domain, but you can certainly use the genSSLKey script provided within the docker. You can try running with the environment variables REGENRATESSL_CERT=true and SUBJECT=/C=US/ST=CA/L=CITY/O=ORGANIZATION/OU=UNIT/CN=localhost (change the values for your needs) The first time you run with these, it'll create the ssl certs in /https and then you can remove those variables for the next run.

Quick update - after a docker restart my owncloud came back up and running. I'm not sure what the issue was, but it looks to be working now. No telling how long it'll stay up for.

If you file an issue with him, itmay be worth it to include th lgs in /var//lib/mysql/*.err This is what mine looks like: 2015-12-21 10:29:14 47924972562880 [Note] /usr/bin/mysqld (mysqld 10.1.9-MariaDB-log) starting as process 128 ... 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: The InnoDB memory heap is disabled 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Memory barrier is not used 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Compressed tables use zlib 1.2.8 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Using Linux native AIO 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Using CPU crc32 instructions 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Initializing buffer pool, size = 128.0M 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Completed initialization of buffer pool 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Highest supported file format is Barracuda. 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: The log sequence numbers 1616819 and 1616819 in ibdata files do not match the log sequence number 1616849 in the ib_logfiles! 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Database was not shutdown normally! 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Starting crash recovery. 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Reading tablespace information from the .ibd files... 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Restoring possible half-written data pages 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: from the doublewrite buffer... 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: 128 rollback segment(s) are active. 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Waiting for purge to start 2015-12-21 10:29:15 47924972562880 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.26-74.0 started; log sequence number 1616849 2015-12-21 10:29:16 47925289838336 [Note] InnoDB: Dumping buffer pool(s) not yet started 2015-12-21 10:29:16 47924972562880 [Note] Plugin 'FEEDBACK' is disabled. 2015-12-21 10:29:16 47924972562880 [Note] Recovering after a crash using mysql-bin 2015-12-21 10:29:16 47924972562880 [Note] Starting crash recovery... 2015-12-21 10:29:16 47924972562880 [Note] Crash recovery finished. 2015-12-21 10:29:16 47924972562880 [Warning] Failed to create a socket for IPv6 '::': errno: 97. 2015-12-21 10:29:16 47924972562880 [Note] Server socket created on IP: '0.0.0.0'. 2015-12-21 10:29:16 47924972562880 [Note] /usr/bin/mysqld: ready for connections. Version: '10.1.9-MariaDB-log' socket: '/run/mysqld/mysqld.sock' port: 3306 MariaDB Server

Hmm... I'm having the same issue. I'm not actually the author of the docker - I just provided the template. Can you post an issue with him? https://github.com/l3iggs/docker-owncloud

Edgar, Make sure that you are accessing using a url such as: http://tower:8080/habmin/ Other then that, I would guess something is screwed up with either the addon(s) for habmin being deleted or the webapp altogether being deleted. This is often a problem using java based applications - configurations get screwed up often and easily. I find openhab is extremely susceptible to errors in configuration. I'm a bit slammed with work ATM, so the best thing I could do for you is to suggest starting the docker fresh, make sure you can access habmin, and slowly integrating your configuration back in.

I just updated the docker and I believe I *may* have fixed the issue. Can you update and let me know if it works for you?

Potentially. I thought I added in all the commands to port the nzbget.conf file for the new docker. Can you send me your nzbget.conf file in a PM? Leave out any username/password info that you don't want to share.

That looks pretty good. I could do a full edit just to make the text read a bit better if you like. You may want to explicitly tell the user what commands to try when migrating dockers before starting fresh. Your user base has the ability to grow quickly and may contain people without much true hands on Linux knowledge. It may also be important to tell users that you can't change the ABC user's uid or gid after the first time the docker is run without manually issuing the chown. Simply changing the environmental variables may cause the docker not to run.

Sounds like a good idea. I think it's completely reasonable to force users to either set permissions themselves or to check that things are compatible before migration. It's a bit difficult to do when each docker uses slightly different directory structure for config so simply documenting the directory structure and required files may be a good start.

It didn't work when I migrated from a different docker with different permissions to this one. I fixed it by manually fixing permissions so I guess this is only for migration cases.

Hey Bungy Our base image sets chown to abc on /config, then we run all processes as abc so any new file would have the correct ownership. https://github.com/linuxserver/docker-baseimage/blob/master/10_add_user_abc.sh Is everything working how it should? I think the problem is here: chown abc:abc /config It doesn't recurse into the directory. I think it needs the -R flag.

I just tried this image and it seems it doesn't automatically chown -Rv abc:users the /config directory.

Yeah, this is definitely brand new terrotiroy for google! Does the /dev/ttyS0 or /dev/ttyUSB0 show up in unraid? If so, you may be able to pass those through directly to the openhab container instead of trying to pass the usb device. Otherwise my guess is the driver needs to be installed in the container and maybe the host.

I have been through something similar to this with my mochad container. I pass through a usb device in order to send X10 commands. I do this by mounting the device "/dev/bus/usb/004" to "/dev/bus/usb/004" in the container. You can figure out which usb bus the device is plugged into by typing lsusb on the unraid terminal. The Bus number tells you which device to pass through. In my example, the X10 controller is on Bus 004 so I pass through /dev/bus/usb/004 To check if your device is passed through properly, enter the bash terminal for the openhab docker (docker exec -it openhab bash) and see if the device /dev/ttyS0 or /dev/ttyUSB0 show up (ls -l /dev)

The other thing you can try is forwarding port 8000 and then accessing through http://WANIP:8000/owncloud The downside here is your traffic is routed through http instead of https and will therefore be unencrypted. Trying this may help to reveal any packet forwarding issues that you may have and should probably not be used in the long term.

The default port mapping is for port 8443 being routed to the owncloud container and it looks like you're using port 8442. Have you double checked which port you're actually using? This may be the reason that the port forwarding from the router is not working. Double checked, ports forwarded correctly on router. I had something on 8443 already, which is why I had to swap it to 8442. I normally use an apache reverse proxy to access my owncloud remotely so that I don't have to open up a lot of different ports. I just tried forwarding port 8443 from my router to my unraid machine, and it worked perfectly. Accessing via https://WANIP:8443/owncloud got me right to the interface. I'm not quite sure what's wrong with your setup, but I'll think about it for a while.

The default port mapping is for port 8443 being routed to the owncloud container and it looks like you're using port 8442. Have you double checked which port you're actually using? This may be the reason that the port forwarding from the router is not working.

Dave, I just pushed an update to the docker template that should fix the links for the webui. If you have already created your container, go change the webui link to http://[iP]:[PORT:8000]/owncloud if you're not using https or https://[iP]:[PORT:8443]/owncloud if you are using https

Sorry I couldn't help. I'm out of my element without having that hardware and knowing how it all works together.

It looks like that configuration option is optional. Have you tried it without that config?

Try running docker exec -it openhab ifconfig Grab the eth0 ip address and set the ip address to that number. This is a dirty hack since this ip will change when the container restarts, but it should at least tell you if that part of the config is the problem. That message you're getting occurs pretty frequently for me too (and many others). I, or others, have yet to see any adverse effects so I've been ignoring it for the time being.

It looks like it's still trying to connect using the RPi's ip 2015-09-01 17:54:01.332 [ERROR] [b.k.i.connection.KNXConnection] - Error connecting to KNX bus: on connect to /192.168.178.100:3671: Invalid argument

Ahhh i see. Try setting that IP to 127.0.0.1. I believe that it should be connecting to the openhab docker and not to the host (unraid).

Hmm and it works in your pi with the same version of openhab and the same binding version?