[SOLVED] Docker-compose fails to start up again

Hello,

after 2 years of running Nextcloud without any problems I yesterday decided to use my ubuntu-Server which is running Nextcloud on docker-compose to also have it run to be my pyload-Server (a headless downloading software for linux, similiar to jdownloader).
So I changed my docker-compose.yml accordingly.
When I did docker-compose up the starting process failed because of a port already in use. Unfortunately, I only then figured out that the pc was running a docker container but not within docker-compose: it was a portainer instance running on port 8000 just as pyload tried to bind with port: 8000:8000
After that, I first tried not to bind the port with “Port: 8000”, now the problems started happening. Other trials with “Port: 8800:8000” didnt work as well so I just commented the pyload-part in my docker-compose.yml.
But I still couldnt start up the docker-compose:
When just starting the computer, the docker-compose failed to load. According to Portainer, the Nextcloud-app stopped with a error in apache:
[Mon Aug 23 08:13:30.777613 2021] [core:notice] [pid 1] AH00094: Command line: ‘apache2 -D FOREGROUND’

[Mon Aug 23 08:13:59.888189 2021] [mpm_prefork:notice] [pid 1] AH00170: caught SIGWINCH, shutting down gracefully
afterwards, all other projects received a kill signal, it seems

When I try docker-compose up, the process of starting up is happening but with lots of messages. So the nextcloud webpage works but I cannot change the user. in the terminal with docker-compose up lots of messages are appearing and showing issues.

Now I’m lost as I really have no clue on what to do:

  • where should I look for logs?
  • what should I do to restart the whole project without loosing to much of my config and data?

I would be so happy if someone could help me. My wife is a teacher and her whole data is on nextcloud. The data is not lost but she relies on a functioning cloud space…

Thank you so much!

Here is my docker-compose.yml:

version: ‘3’
services:
proxy:
image: jwilder/nginx-proxy:alpine
labels:
- “com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true”
container_name: nextcloud-proxy
networks:
- nextcloud_network
ports:
- 80:80
- 443:443
volumes:
- ./proxy/conf.d:/etc/nginx/conf.d:rw
- ./proxy/vhost.d:/etc/nginx/vhost.d:rw
- ./proxy/html:/usr/share/nginx/html:rw
- ./proxy/certs:/etc/nginx/certs:ro
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/tmp/docker.sock:ro
restart: unless-stopped
letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
container_name: nextcloud-letsencrypt
depends_on:
- proxy
networks:
- nextcloud_network
volumes:
- ./proxy/certs:/etc/nginx/certs:rw
- ./proxy/vhost.d:/etc/nginx/vhost.d:rw
- ./proxy/html:/usr/share/nginx/html:rw
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: unless-stopped
db:
image: mariadb
container_name: nextcloud-mariadb
networks:
- nextcloud_network
volumes:
- db:/var/lib/mysql
- /etc/localtime:/etc/localtime:ro
environment:
- MYSQL_ROOT_PASSWORD=xxxx
- MYSQL_PASSWORD=xxxx
- MYSQL_DATABASE=xxxx
- MYSQL_USER=xxxx
restart: unless-stopped
app:
image: nextcloud:latest
container_name: nextcloud-app
networks:
- nextcloud_network
depends_on:
- letsencrypt
- proxy
- db
volumes:
- nextcloud:/var/www/html
- ./app/config:/var/www/html/config
- ./app/custom_apps:/var/www/html/custom_apps
- ./app/data:/var/www/html/data
- ./app/themes:/var/www/html/themes
- /etc/localtime:/etc/localtime:ro
environment:
- VIRTUAL_HOST=xxxx
- /etc/localtime:/etc/localtime:ro
environment:
- VIRTUAL_HOST=xxxx
- LETSENCRYPT_HOST=xxxx
- LETSENCRYPT_EMAIL=xxxx
- NEXTCLOUD_HOSTNAME=xxxx
restart: unless-stopped
pihole:
container_name: pihole
image: pihole/pihole:latest
restart: unless-stopped
ports:
- “53:53/tcp”
- “53:53/udp”
- “8080:80”
- “4430:443”
environment:
TZ: ‘Europe/Berlin’
WEBPASSWORD: xxxx
volumes:
- ‘/opt/containers/pi-hole/pihole/:/etc/pihole/’
- ‘/opt/containers/pi-hole/dnsmasq/:/etc/dnsmasq.d/’
dns:
- 127.0.0.1
- 1.1.1.1

volumes:
nextcloud:
db:

networks:
nextcloud_network:

hi,

I didn’t read all the error as it look little cumbersome what you explain.

In my experience docker-compose only fails to start if you have major issues:

  • format of the config file
  • used ports
  • invalid volume mappings

other issues like configs in/out-side of the container or incompatible versions you find using usual troubleshooting methods (e.g. logs of specific components).

I would suggest following approach:

  • find our what you want to achieve (volumes, hostnames, network relations)
  • review your config file syntax (docker-compose config)
  • check the logs for errors (every single component: DB, application, reverse proxy-if any)

if you don’t find the issue post more specific errors/log snippets so experienced users could help you.

docker logs <container name>

is usually good place to start…

find our what you want to achieve (volumes, hostnames, network relations)…

From your error description I can’t really say what’s going on, a bit more detail would be required, but I noticed two things in your compose file which I would change.

First, you seem to add everything into one big docker-compose file (PiHole?) Well, the downside of this is that if an error occurs in one component everything else may be affected too. My advise would be to create separate docker-compose files for each service, so everything Nextcloud is in one file, and a separate one for e.g. PiHole. In that way you avoid artificial dependencies.

The even bigger issue though is the fact that you are using :latest as tag for your images. This means that during troubleshooting Portainer (down / up) you likely also added new versions of your other images to your stack and now you might be dealing with new issues which the new images have introduced.

You may now have gotten yourself the latest MariaDB image which according to other threads I have seen breaks Nextcloud and needs manual intervention to work again? I am just guessing but I think it’s work checking for related messages in the messages you get with docker-compose up

My recommendation would be to always use the version tag, e.g. nextcloud:21.0.4 so you update when you decide and not when you restart your containers for a completely different reason.

Edit: By the way, before you make any sweeping changes I would advise to make a backup of
./app so you don’t lose your data and config by accident.

2 Likes

I’m so happy that you took your time to have a look on my problem.

@tomz: this is wonderful, thank you so much for your advice.

I will do as you say: i just found an old backup of my whole drive which I will try to restore. Before running docker-compose up I will prepare two different docker-compose and I will make sure to use a version of Nextcloud I’m sure was running fine.

I’m so happy right now for your help. I dont know what to say! Thanks a lot!

2 Likes

Not sure if the “damage” is big enough to require a full restore? Maybe it is indeed just the MariaDB upgrade which preventsxNextcloud from starting? If so, the fix is a simple settings change.
There’s also quite a bit one can learn when troubleshooting. :slight_smile:

Just a follow up to what @tomz said about the MariaDB update.

I did a docker-compose pull, it grabbed MariaDB 10.6. After shutting down, I changed the docker-compose.yml file to:
image: mariadb:10.5
did another docker-compose pull, and everything started working again without any issues. Apparently nothing happened while it was running 10.6 that caused the version roll back to malfunction. No need for restoring any backups.

1 Like

Dear everybody, I’m so happy right now!

I just did what was proposed:

  • adding nextcloud:20.0.4 to my docker-compose instead of nextcloud:latest (as I checked my config.php and it was still this version)
  • adding mariadb:10.5 (instead of just mariadb, I guess it got updated to 10.6)

Afterwards, I couldnt log into Nextcloud because of missing writing privilegies for the nextcloud user. When checking I realized that my restoring effort (using my duplicati backup) messed up the ownership of the Nextcloud “app”-folder. Now it was all www-data:root, so chown it back to www-data:www-data and it worked again.

Thank you so much again for your wonderful help and support. And indeed, now I learned something about docker as well as the potential problems of uncontrolled updates…

All the best to all of you guys!

1 Like