Thanks for getting beck to me.
I have set a pfsense as my firewall so I guess it should be something doable though this?
PFSense sounds so powerful, there would probably be a hundred different ways how to do it in there, but I haven’t used it myself yet… 
2 Likes
Indeed it is but you have to be way more knowledgeable than me 
There are dedicated DNS forwarder and DNS resolver functions but I honestly don’t know where to start!
Yeah, sorry I don’t know. I would just try it out and see what it does. If you get stuck I’d recommend to find some PFSense help forum.
2 Likes
Thank you. I appreciate your time 
I know this answer is a little off-topic since it really is pfSense configuration, but since @gtj has already posted here, and I have knowledge to share, there is no sense in having the two of us migrate this to the pfSense forums just yet, although we can if we need to delve deeper into it.
Configuring your DNS so that your ownCloud is accessible at the same host name from both the LAN and the public internet should solve your problem. If you are on a dynamic IP you have two distinct problems to solve. The good news is that you can solve both of them with pfSense.
The first problem you have is to keep a public DNS record updated with your dynamic IP when it changes. See the Dynamic DNS section of the pfSense Documentation for details on setting that up. You will then use that hostname in your ownCloud client on your mobile device.
That leaves you with one more problem which can also be solved in pfSense, as long as you are using it as your DNS resolver on your LAN. The solution to your problem for LAN access is to essentially create a split DNS record for the public hostname.
In the General Settings of the DNS Resolver Service in your pfSense you will see a Host Overrides section where you can configure an entry for your ownCloud server. Be sure to use the public hostname and domain provided by your DDNS service provider and the local IP of your ownCloud server. If you have a simple network, that should be all that you need to do.
The best part about having this setup is that you could configure Let’s Encrypt on your ownCloud server, and the certificate will work just fine on both on the public internet, and on your LAN. Depending on how your port forwarding is set up, you may need to reconfigure some things to get that working, but that’s a separate topic you can address after you get your current situation resolved.
I hope this helps, and good luck!
2 Likes
Thank you so much for such a helpful response!
I already use No-IP Dynamic DNS service and I have configured it within pfSense.
I’m also nearly there with regards to setting the host in DNS resolver.
I have set the IP of my ownCloud server and I can call it with its domain but my problem is that I still have to change between LAN and 4g as the external (forwarded) port which corresponds to the domain is different than the internal ‘‘80’’ HTTP port than listen to the local IP of the server. I know I’m quite close but I don’t seem to find a solution on this. I tried experimenting putting a port number after the domain (both internal & external) to no avail. The DNS resolver settings don’t allow for any port setting too. You are only allowed to set a host, a domain and server IP. If you set a ‘’:’'followed by a port you cannot save the DNS resolver settings!
You can’t set ports in DNS. The only solution to your problem is to use the same ports on the internet and on the LAN. We’re not going to waste any time discussing running a reverse proxy internally on the non-standard port because, while it could work, it is a lot of unnecessary effort that will leave you with an overly complicated set up that just isn’t worth it.
You have two choices. The better one is to forward ports 80 & 443 on the internet side. The less desirable is to update your Apache configuration to use the non-standard ports that you are currently using on the internet. Unless your ISP actively prohibits running services on your circuit, don’t use that second option.
If you haven’t already, you will need to turn off the WebGUI redirect option in pfSense under System/Advanced so it doesn’t override your port forward from port 80. Port 80 brings us to the next topic that must be discussed.
Please don’t run a publicly accessible ownCloud without using HTTPS. The only thing you should be running on port 80 is an HTTP redirect to HTTPS on port 443 (with a possible exception for the well-known acme-challenge if you need it to validate certificate issuance). Running an ownCloud server on an unencrypted HTTP connection on the internet is invitation for disaster that can only lead to regret.
This is the twenties. We live in the age of Let’s Encrypt, where getting a free, recognized certificate is nearly as easy as ordering a pizza. There are a variety of methods to get Let’s Encrypt running on your server. The easiest options are available if you can forward port 80 to facilitate HTTP-01 validation. Look into Certbot, or Apache MD (mod_md) if you are running a new enough Apache version. If you are on Debian Buster, you will need to be on the package from the Buster Backports for Apache MD to work properly. If you can’t use HTTP-01 or TLS-ALPN-01 validation, you might look into the DNS-01 capabilities of Dehydrated.
2 Likes
I wanted to thank you so much for both these posts above.
I made it but God knows how much I suffered 
Honestly without your help I couldn’t have set it up as you explained thoroughly the process and the logic behind.
I faced up countless problems and had to debug almost every single step but somehow knew it was going to get rewarding at some point! Even if I had to spend the better part of the day…
I hope my new OC serves proves rock solid!
Thank you so much once again sir!
1 Like
I’m glad to hear that you were able to accomplish your goal. I hope your ownCloud is able to give you many satisfying years of service.
Don’t forget to install updates as they become available. It’s a lot easier that way than it is trying to catch up later. Most importantly, have fun!
2 Likes
Thank you!
So far it exceeds my expectations. Very responsive and fast self-maintained cloud and mind you, I’m only running it on a RPi2
Since I’m running my OC instance on a DietPi, is it safe to assume that a DietPi update will take care of the regular update process?
I had not heard of Diet Pi. It looks pretty neat. If you installed ownCloud using Diet Pi, from what I can see on their site, I would expect it to part of their own upgrade process, but I’m not intimately familiar with that Distribution. I’ll have to test drive it some day for kicks. 
2 Likes
Assumptions are the source of all evil, especially in the IT.
Unfortunately the oC upgrade process is not automated at all, so I would assume that DietPi didn’t fix that.
Have a look at the following article and make sure to test your upgrade process before you might destroy a “production” instance:
https://doc.owncloud.com/server/admin_manual/maintenance/manual_upgrade.html
2 Likes
Oops.
Sad to see it’s such a complicated process. I’m fairly sure I can do that by following the detailed documentation, however I fear something will break down the line from all the features and parameters I had to set in order for it to work as I want it.
I’m wondering if cloning the Pi microsd card is a good way to at least preserve a working instance of my current 10.5 setup?
If Dietpi could automatically update its software along with kernel updates, that would be awesome!
I think it’s a good idea to drop a question over at their forum.
Absolutely. All ownCloud settings are in the config.php and the database, have a look in the how to backup docs article for more information on how to backup your installation.
2 Likes
I’d additionally create a database dump, which contains the SQL commands to re-create the database. That way one can recover the database to every database server/system version. As it’s actually a “text” file (no binary), one could even recover single tables and/or meta data and all that:
mysqldump owncloud > /path/to/owncloud_backup.sql
Indeed it’s a bid strange that the official recent ownCloud docs only promte the manual procedure even that there are two simple automated ways available:
- Use the web UI > Settings > General > Start upgrade (or similar wording).
- As on larger instances, a web UI updater always bears the risk to leave you in an unconditional state, when the browser connection gets lost in the middle, especially for larger instances it’s better to do that from server console:
Entersudo -u www-data php /var/www/owncloud/updater/application.php1to being.
I can only assume that ownCloud wants to reduce being held responsible for broken instances if anything fails within the automated upgrade methods. Now they can say, “Hey, read the docs where we told you to upgrade manually!” .
Best, as always, is to contribute this information or raise an issue about on the GitHub repository:
2 Likes
May I ask where is it recommended to store that database dump file? Is it safe to keep it inside DietPi’s OS sd, Oc’s storage or better yet outside on a third party drive?
The reason why they’d promote the complicated upgrade is valid indeed.
Great stuff once again. Thank you!
I’d keep them on an external drive, i.e. a different drive then where the actual database files are stored. I personally create a dump every night onto the same data drive and sync it, together with all data and some important configs onto a second backup-only drive.
But it depends on your usage. The database does not contain the actual data files, but all meta information like tags, comments, shares and what other apps might add, of course app configs/data (calendar, contacts, …), user profiles etc. If you use ownCloud mostly by yourself to access your data from multiple devices, there is probably not much relevant information and doing a fresh ownCloud install (at least on DietPi quickly done) + copying files inside + occ files:scan --all (or alternatively upload from clients) is all to bring you back online in case of SD card death.
2 Likes
Thank you so much for the very helpful info!