Derek Andrews's picture

I am sill a biginner with linux, but have been running samba, owncloud, and joomla containers on a server. I built each of these from scratch on the basic turnkey container and they have been running for about 18 months with no (known)  problems. However, when there is a powr cut the server reboots automatically but the owncloud container is not visible outside of my local network. If I log onto the container with putty and do

  /etc/init.d/networking stop

  /etc/init.d/networking start

or equivalently (I hope)

  /etc/init.d/networking restart

all is ok and owncloud is visible on the web.

How can I get the network working so that this happens automatcally.

Help for a beginner would be appreciated --- thanks

/etc/init.d/networking restart/etc/init.d/networking restart/etc/init.d/networking restart/etc/init.d/networking restart/etc/init.d/networking restart/etc/init.d/networking restart/etc/init.d/networking restart

Jeremy Davis's picture

Preferably you shouldn't be cutting the power to a server without shutting it down. Ideally you should look to implement something that will ensure that your server always shuts down "cleanly" (e.g. a UPS). I'm guessing you know that already, so moving on...

It's probably worth trying to understand more about your scenario. You note that only your ownCloud container exhibits this behaviour and it only effects external connections. Is ownCloud the only server that is available externally? If so then perhaps it effects other servers too but you just don't realise? If not then are there differences within your network config (within your LAN and externally) that may be causing the different servers to act differently?

One of the first things I would check is if this same situation occurs if you reboot the host server cleanly? If it does, then obviously the unclean shutdown is not the issue, but the start/restart of your host server. Either way it will help whittle down to the cause.

Moving to your network; when you externally contact your ownCloud server, do you do it via a domain name or an IP? If via a domain name do you have a static (external) IP? If not are you using some sort of dynamic DNS provider? How does the external IP map to the internal IP (e.g. router port forwarding)? Do your containers have direct access to the LAN (via bridged networking) or are they NATed (and port forwarded) by the host? If bridged, does your container use a static IP? Do you have an internal (i.e. within your LAN) DNS server (e.g. BIND or DNSMASQ), or are you using something like ZeroConf (or some other broadcast system that allows mapping hostnames to IPs)? What else might be changing within you network during the host server restart?

So in short, I recommend hunting out what the actual problem is and I would expect that it's a weakness in your network config rather than anything actually "wrong" with your ownCloud server config. As a totally wild guess (with far too little info) I suspect that you are using some sort of dynamic network config, which isn't being appropriately updated on reboot of your ownCloud server.

OTOH if you would rather just work around the issue without trying to understand the cause then you could probably just create a new daemon (TKL containers use sysvinit - all other builds use SystemD) and/or a cron job that checks external connectivity and restarts the networking if it can't contact itself via external connection.

Derek Andrews's picture

I am in the process of regenerating my containers on Debian Jessie. I am using the generic template from this site and it installs version 14.0 of everything --- I want 14.1 versions. Managed to find the changes I need to do with the generic template; however, though it sort of works, it fails to find most of the sites to download software it needed, the sites are now missing. What other changes do i need to make? I have looked at the code and it is not obvious to me.

Better still, is there a newer version of the template?

Even better, could it be placed in a more obvious place?


Derek Andrews


Jeremy Davis's picture

Ah yes, that's a known issue in the v14.1 appliance: As posted in the thread there, the workaround is to explicitly set the version. E.g.:
lxc-create -n fs1 -f /etc/lxc/bridged.conf -t turnkey -- fileserver -v 14.1-jessie
We are planning to automate it to always download the latest version for the v14.2 release.

Add new comment