Access Server from remote via the Android app

Hello everybody,

I’m new to ownCloud and have successfully set my server and port forwarded the corresponding port for remote access.

Now I can reach my server and connect to it as normal with my mobile data connection (via my WAN address) but when I’m at home I have to manually switch to a ‘‘LAN profile’’ which is technically the local IP address of my server, otherwise it won’t connect.

For that reason I have set 2 ‘‘accounts’’. One for LAN and one for WAN access and I’m constantly switching between them. I’m sure that’s not how it is supposed to be as it defeats the purpose of automatic back ups.

Any help will be greatly appreciated!

What am I doing wrong?

You could try to use dnsmasq in your internal network.

See previous discussions:


Hi Michael. Is there a tutorial that I could possibly follow for setting this up?
Many thanks

I’m wondering whether this can be achieved with a DNS service like ‘‘No-IP’’?

Depends on if your router box supports routing of internal traffic to the external WAN address and back into the internal network.
You can easily test that by trying to access the WAN IP from the internal network. If that doesn’t work you need dnsmasq.
A service like No-IP is just a regular dynamic DNS service (AFAIK), which will allow you to tie a DNS hostname to your ever changing home IP address.


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… :wink:


Indeed it is but you have to be way more knowledgeable than me :smile:

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.


Thank you. I appreciate your time :slight_smile:

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!


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.


I wanted to thank you so much for both these posts above.
I made it but God knows how much I suffered :stuck_out_tongue:
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!


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 :slight_smile:

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. :grin:


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:



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.