Nextcloud - Letsencrypt issue

uid=1004(docker1) gid=1004(docker1) groups=1004(docker1)

I think the issue could be that I am deploying on a Raspberry Pi4...apparently there are some MariaDB issues

I dont have a RPi4 around to test it. But I tried it on my Odroid HC2 (armhf). It worked without any issues.

My user is called "docker". UID 1000 GID 100. (I did not set up letsencrypt/swag).

version: "2"
services:
  nextcloud:
    image: linuxserver/nextcloud
    container_name: nextcloud
    environment:
      - PUID=1000 #change PUID if needed
      - PGID=100  #change PGID if needed
      - TZ=Europe/Berlin #change Time Zone if needed
    volumes:
      - /srv/dev-disk-by-label-backup/appdata/nextcloud/config:/config #/srv/dev-disk-by-label-disk1 needs to be adjusted
      - /srv/dev-disk-by-label-backup/appdata/nextcloud/data:/data     #/srv/dev-disk-by-label-disk1 needs to be adjusted
    depends_on:
      - mariadb
    ports: # uncomment this and the next line if you want to bypass the proxy
      - 450:443
    restart: unless-stopped
  mariadb:
    image: linuxserver/mariadb
    container_name: nextclouddb
    environment:
      - PUID=1000 #change PUID if needed
      - PGID=100  #change PGID if needed
      - MYSQL_ROOT_PASSWORD=mariadbpassword  #change password
      - TZ=Europe/Berlin #Change Time Zone if needed
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=somepassword
    volumes:
      - /srv/dev-disk-by-label-backup/appdata/nextclouddb:/config    #/srv/dev-disk-by-label-disk1 needs to be adjusted
    restart: unless-stopped

so if you run it without swag/letsencrypt you can just call the server via internal IP or how does it work?

As you can see I exposed port 450(443) of the nextcloud container on my host. But this is just a test setup. When you access the setup page through your swag/letsencrypt container it will aumatically put the right variables in the config.php of nextcloud.

ports: # uncomment this and the next line if you want to bypass the proxy
      - 450:443

PS: some more info

$: ls -la /srv/dev-disk-by-label-backup/appdata/
total 16
drwxrwsrwx 1 root   users 40 Nov 22 18:13 .
drwxr-xr-x 1 root   root  88 Nov 22 17:13 ..
drwxr-sr-x 1 docker users 20 Nov 22 18:13 nextcloud
drwxr-sr-x 1 docker users 44 Nov 22 18:13 nextclouddb

my user docker1 has his own group. Is that an issue?

root@pi3:/srv/efca6135-103c-48ee-825f-f67b5b48e322/appdata# ls -all

total 20

drwxr-xr-x 5 root root 4096 Nov 22 19:57 .

drwxr-xr-x 8 root root 4096 Nov 22 12:37 ..

drwxr-xr-x 4 root root 4096 Nov 22 19:57 nextcloud

drwxr-xr-x 4 docker1 docker1 4096 Nov 22 19:51 nextclouddb

drwxr-xr-x 12 docker1 docker1 4096 Nov 22 12:38 swag

Zitat von MarcS

my user docker1 has his own group. Is that an issue?

No,I don’t think so...

The name of your disk indicates that it is a mergerfs volume? I never tried, but heard there might be issues when storing docker config files on a mergerfs volume. You might give it a try and use a specific disk as the target for the docker config folders

Hello Morlan - I think your tip with mergerfs was brilliant. I changed the Docker path as you suggested. (I would have never thought that this has an impact)

I then re-ran the containers and when accessing Nextcloud via internal ip, I got errors about wrong password which I did fix. But it showed, that for the first time Nextcloud was connecting to MariaDB. After fixing the password, Nexcloud went into a 30sec delay and a new error appeared. This time its an nginx timeout page (below) but I do think I am 1 step closer. Do you know what might be going on here?

Yes just refresh the page. If the setup page reappears don't enter the credentials again. wait some more and refresh.

This just means that the nextcloud setup takes longer and the browser times out automatically

I AM IN!!!

You genius! thank you so much for your help.

I want to write this issue into a mergerfs and a Docker README file. We should document this as this is one of those things that I would have never ever thought of. I had amended all the disk paths inside the docker-compose.YML but never thought that it would impacet Docker in such a strange way. Docker did not throw an error any time before that. Isn't that strange.

I'm glad we were able to work it out.

macom maybe you could add a comment to your guide about the caveat of storing container configs on a mergerFS mount point?