Limit access to NextCloud to only "Trusted" networks

NethServer Version: 7.9.2009
Module: NextCloud


Is it possible to limit access to NextCloud to only “Trusted” networks.
A similiar option exists for a lot of NethServer Modules like DokuWiki:

Example Dokuwiki:

config setprop dokuwiki access private


config setprop dokuwiki access public

then the usual

signal-event nethserver-dokuwiki-update

Thanks for any hints.

My 2 cents

Hi Andy,

is Brute-Force IP Whitelist an optiom?



Firewall is installed on the device?
Green only? Or another device (you have a soft spot for OPNSense) in front?

Hi @transocean

No, as NethServer itself should remain accessible. LetsEncrypt are still needed, even if NextCloud is Internal only.

Hi @pike

On NS7, there is always a firewall, no matter if you install it or not. If you install Firewall, you get a GUI, and some pre cooked stuff.
And yes, Green only, a 16 GB RAM VM with 8 Cores on Proxmox. And OPNsense in front, as a dedicated box, not as a VM.

The biggest issue is the distance, that server is half the world away from me (+ 10000 km). And in that context, time shift, communicating with people…

Hope that answers all questions! :slight_smile:

My 2 cents

At the moment, the easiest solution would be:

Limit NextCloud login to domainname and local IP, but not Internet IP.
The domain only exists internally.

The VPN enforces the use of the internal DNS, and additionally routes ALL trafic to NethServer.

In this use case, SSL cert is a non-issue, as we can / will provide self generated certs and have these embeddded in the allowed clients (Master Image).

A logical switch like other Modules have might have been easier (and maybe more secure), but the above will work and is a valid workaround.

I’m still open for better ideas…

My 2 cents

1 Like

Hi Andy,

looking at the code of the nethserver 7 module for nextcloud it doesn’t have this feature;
in de Apache e-smith configuration access is hard coded to all granted

IIRC to limit access from trusted networks you need a space-separated list of (trusted) IP’s on this place like:

Require ip

maybe test this while the other half of the world is at sleep :wink:
if it works we can try to bake a custom template…

1 Like

Hi Mark

I suspected as much, after testing and not finding any snipplet in the Templates.

But do not worry, I have good knowledge of the E-Smith system to do this myself, and post the result for anyone in a Howto os such.

I was a vivid user of SME-Server, previosuly called E-Smith… :slight_smile:

I don’t consider myself a coder, but any Sysadmin worth the titke can code scripts and more…
And I’ve modded more than my share of E-Smith Templates!

My 2 cents

1 Like

I’m definitely considered myself a coder, the fact I do not really understand the snippet below proves that…

Somehow this delivers the string with space-separated ip’s/submask’s for the configured trusted networks…

As a self considered non-coder, here’s my translation (attempt).

use esmith::NetworksDB;

Uses the e-smith Template system.

my $ndb = esmith::NetworksDB->open_ro();

Variable defined $ndb as the e-smith DB (var/lib/nethserver/db)

my @localAccess = $ndb->local_access_spec();

Defines an “Array” of networks or hosts considered local (or “Trusted” in the GUI)

$localAccess .= join ' ',

Fill in the variable with: An Element of the array, followed by a space. (“.=” defines the array element,
and the space in apstrophe is the space), and continue looping until array is finished.

map { s:/; $_ }

This generates the line and subnet for each entry.

This is a non coder reading and trying to explain what this code snipplet does, step by step, to a coder!


Hope it is comprehensible, makes sense and is the actual programming steps per line!

My 2 cents

1 Like

those are good ideas. As well as at apache level as Mark suggested as an option.
There’s also a nextcloud app (limit_login_to_ip) that is supposed to do something similar (external access to nextcloud UI is possible but login is limited by IP range). Not exactly the same… and unaware if it also restricts desktop/mobile app access if conditions are met. The first two options you both mention are probably more reliable/secure long term.

1 Like


This is explictely not allowed by the client. Access by VPN is restricted to the Client.


Simplifies the issue for me!

My 2 cents