uid=1004(docker1) gid=1004(docker1) groups=1004(docker1)
Nextcloud - Letsencrypt issue
-
- gelöst
- STUKguy
-
-
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).
Code: docker-compose.yml
Alles anzeigenversion: "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.
PS: some more info
-
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
-
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.
-
-
maybe you could add a comment to your guide about the caveat of storing container configs on a mergerFS mount point?
done
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!