Minimal working nextcloud config

I’d like to get a minimal nextcloud setup working. Preferably, it should run in a NixOS container.

Here’s what I’ve got so far:

# Compatible with NixOS >= 20.09
{
  containers.nextcloud = {
    autoStart = true;
    privateNetwork = true;
    localAddress = "10.50.0.2";
    hostAddress = "10.50.0.1";
    config = { pkgs, config, lib, ... }: with lib; {
      networking.firewall.enable = false;
      services.nextcloud = {
        enable = true;
        hostName = "10.50.0.2";
        # nginx.enable = true; # Uncomment for NixOS < 20.09
        config = {
          dbpass = "admin";
          adminpass = "admin";
        };
      };
    };
  };
}

Edit: The above works indeed fine, my issue was that I used the wrong external interface address to connect to the container.

nextcloud is now reachable from the container host:
curl -L 10.50.0.2

Original question:

The services (phpfpm-nextcloud, nginx) are running without errors or warnings, but on firefox 10.50.0.2 the connection times out.

I couldn’t manage to make this work on NixOS 20.03, 20.09 and unstable.
How can I fix this config?

2 Likes

nixos containers are systemd nspawn containers…

what does

nixos-container status nextcloud

give you?

nixos will create the container, but won’t automagically start it.

you may want to LXC containers instead… but your test code above should work.

https://github.com/nixcloud/nixcloud-container

1 Like

The container and its nextcloud-related services are running.
To clarify this, I’ve added autoStart to the config.

where are you running firefox? on the host your running the container or
external (i.e on the network , not on the host?).

nspawn container don’t expose thier services to the rest of the network, for that you have to port forward to the from the host’s networking stack to the container.

1 Like

Thanks for the hint, I’ve just noticed that it works on localhost:

sudo nixos-container run nextcloud -- curl -L 127.0.0.1 # Works, serves HTML
sudo nixos-container run nextcloud -- curl -L 10.250.0.2 # No response after opening socket
curl -L 10.250.0.2 # No response after opening socket

Strange that nextcloud isn’t reachable on the external interface. The basics look fine:

sudo nixos-container run nextcloud -- netstat -nltp
# ...
# tcp     0    0 0.0.0.0:80      0.0.0.0:*    LISTEN      345/nginx: master p

sudo nixos-container run nextcloud -- ip a
# ...
# 2: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
#   link/ether 92:2a:bc:b1:76:10 brd ff:ff:ff:ff:ff:ff link-netnsid 0
#   inet 10.50.0.2/32 scope global eth0

I’m certain that with privateNetwork = true the container’s external interface (in this case with address 10.50.0.2) is exposed to the container host.

I’m really really sorry, I had a total blackout and used the the wrong external address.

Everything is working fine now, thank you very much for your kind support.
To give this thread any redeeming value, I’ll extend the initial post to show a minimal working example, including a connection via curl.

yeah, but nixos just setup a virtual ethernet interface, not a full layer 2 bridge setup.

arch and other linuxs uses systemd->networkd to all this ‘clever bridging stuff’ behind the scenes…

in the nixos manual it says.

By default, containers cannot talk to the outside network. If you want that, you should set up Network Address Translation (NAT) rules on the host to rewrite container traffic to use your external IP address. This can be accomplished using the following configuration on the host:

networking.nat.enable = true;
networking.nat.internalInterfaces = [“ve-+”];
networking.nat.externalInterface = “eth0”;

https://nixos.org/manual/nixos/stable/index.html#sec-imperative-containers

unless I’m missing something obvious. Although privateNetwork = true , it doesn’t setup a bridge… so it’s not working exactly how you may expect.

You say you have it working now, so perhaps it does do this now???

Good.

does it traffic work both ways now? i.e. traffic to the container from the external network, and from the container to external network. ‘interesting’…

does it traffic work both ways now?

Connections between the container host and the container work natively.
Connections between the container and the external network require NAT, as you explained.
Thanks, again, for your help!

ok, that makes sense to me now. I thought you may of have magic unicorn packets in your system, or elves (gnomes) doing mystical routing. Container networking is sometimes feels that way.

Maybe you can try enabling nat, and see if you come across this bug?

https://github.com/NixOS/nixpkgs/issues/72580

1 Like

Personally I’m enabling NAT this way, which is more specific, faster, and always works reliably:

networking.firewall.extraCommands = ''
  iptables -w -t nat -A nixos-nat-post -s ${config.containers.nextcloud.localAddress} -j MASQUERADE
'';

Which exact NAT config do you want me to check?

1 Like