Nextcloud-aio-nextcloud cannot see appdata after a reboot

ℹ️ Support 📦 Appliances (Docker, Snappy, VM, NCP, AIO)
, , ,
1

I had a Nextcloud instance running perfectly for several months. One day realize its not running and when I tried to reboot it, my Nextcloud-aio-nextcloud docker container is stuck in an endless loop.

I am using Docker Desktop, AIO v10.11.0, on macOS 15.2

The logs from nextcloud-aio-nextcloud are:

2025-04-15T03:51:05.962635211Z Connection to nextcloud-aio-database (172.18.0.3) 5432 port [tcp/postgresql] succeeded!
2025-04-15T03:51:08.023367450Z               now              
2025-04-15T03:51:08.023394505Z -------------------------------
2025-04-15T03:51:08.023399430Z  2025-04-15 03:51:08.018178+00
2025-04-15T03:51:08.023403241Z (1 row)
2025-04-15T03:51:08.023406368Z 
2025-04-15T03:51:08.033026120Z + '[' -f /dev-dri-group-was-added ']'
2025-04-15T03:51:08.033095070Z ++ find /dev -maxdepth 1 -mindepth 1 -name dri
2025-04-15T03:51:08.035086431Z + '[' -n '' ']'
2025-04-15T03:51:08.035158624Z + set +x
2025-04-15T03:51:08.063920018Z Enabling Imagick...
2025-04-15T03:51:10.049789685Z WARNING: opening from cache https://dl-cdn.alpinelinux.org/alpine/v3.21/main: No such file or directory
2025-04-15T03:51:10.049810935Z WARNING: opening from cache https://dl-cdn.alpinelinux.org/alpine/v3.21/community: No such file or directory
2025-04-15T03:51:10.091221238Z Connection to nextcloud-aio-redis (172.18.0.4) 6379 port [tcp/redis] succeeded!
2025-04-15T03:51:11.373222712Z Appdata is not present. Did you maybe change the datadir after the initial Nextcloud installation? This is not supported!
2025-04-15T03:51:11.373242308Z See https://github.com/nextcloud/all-in-one#how-to-change-the-default-location-of-nextclouds-datadir
2025-04-15T03:51:11.373246361Z If you adjusted the datadir to be located on an external drive, make sure that the drive is still mounted!
2025-04-15T03:51:11.373249331Z In the datadir was found:
2025-04-15T03:51:11.375190273Z total 4
2025-04-15T03:51:11.375204838Z drwxr-x--- 2 www-data root   40 Apr 15 03:51 .
2025-04-15T03:51:11.375209576Z drwxr-xr-x 1 root     root 4096 Apr 15 03:51 ..

Just to note, I have not changed the datadir, this was completely working not too long ago.

Here is my compose:

services:
  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock.raw:/var/run/docker.sock:ro
    network_mode: bridge
    ports:
      - 80:80
      - 8080:8080
      - 8443:8443
    environment:
      NEXTCLOUD_DATADIR: /Volumes/G-Raid/nextcloud-data
      NEXTCLOUD_MEMORY_LIMIT: 1024M
      WATCHTOWER_DOCKER_SOCKET_PATH: /var/run/docker.sock

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer

Here are the file permissions:

drwxrwxrwx@ 13 admin  staff   416 Apr 14 20:44 .
drwxrwxr-x@ 10 admin  staff   320 Apr 14 23:04 ..
-rwxrwxrwx@  1 admin  staff  8196 Apr 14 22:16 .DS_Store
-rwxrwxrwx@  1 admin  staff   542 Jan 29 00:10 .htaccess
-rwxrwxrwx@  1 admin  staff    52 Jan 29 00:10 .ncdata
drwxrwxrwx@  8 admin  staff   256 Jan 23 16:00 admin
drwxrwxrwx@ 11 admin  staff   352 Apr 14 22:12 appdata_octe2y19bka8
-rwxrwxrwx@  1 admin  staff     0 Jan  5 23:43 audit.log
-rwxrwxrwx@  1 admin  staff     0 Feb  2 13:33 flow.log
-rwxrwxrwx@  1 admin  staff     0 Jan  5 23:44 fts-index.done
-rwxrwxrwx@  1 admin  staff     0 Jan 29 00:10 index.html
-rwxrwxrwx@  1 admin  staff     0 Jan  5 23:43 nextcloud.log
drwxrwxrwx@  7 admin  staff   224 Jan  6 01:29 test

What I have tried so far is to play with permissions on the files themselves, by doing a sudo chmod -R 777 /Volumes/G-Raid/nextcloud-data and trying some different configurations of owners and groups. None of it seemed to work but I am also a hobbyist and by no means an expert so totally open to having missed something.

Any help is much appreciated :slight_smile:

2

Hello @nblackley, welcome to the Nextcloud community! :handshake:

why?
the right owner for the files would be 33:33 (www-data) and 750 and 640 for directories and files no reason to do do try and error - RTFM helps.

the log tells you the system doesn’t find any data in the datadir (from the container point of view). but this doesn’t match your file listing :thinking: likely you suffer from:

Do not set or adjust this value after the initial Nextcloud installation is done! If you still want to do it afterwards, see this on how to do it.

It’s hard to say how this happened but for me it sounds like you changed something during runtime but this change was not fully applied and with a reboot you returned to some intermediate step…

you seem to mix the Mac ( --volume /var/run/docker.sock.raw:/var/run/docker.sock:ro) and Synology ( --env WATCHTOWER_DOCKER_SOCKET_PATH="/volume1/docker/docker.sock") installation variants…

I’m not such deep into AiO to help you in depth - I would recommend you review all the setting one, two, three more times - removing optional tweaks until you get it running

3

Hey thanks for the reply! I’ll try to tackle each of the suggestions, but I ended up nuking the whole thing and rebuilding it. (See discussion on this reddit thread: reddit.com/r/NextCloud/comments/1jzyxqn/nextcloudaionextcloud_cannot_see_appdata_after_a/)

So the reason I changed the permissions is because I wasn’t quite sure how docker and macOS interacted with file permissions. I know that the file permissions should be owned by www-data, but thats only from the container perspective as I understand it. Mac does not have a www-data user, the default apache user is _www which has 70:70 permissions so I had no idea what the “correct” values were.

I do understand it appears that something changed, but I had not touched the config since deploying it. It had gone through several restarts before.

Your point about mixing the Mac and synology vars in my Docker compose is totally right. I removed the watchtower var when I rebuilt it.

For anyone who sees this post afterward, I pretty much determined that there was no solution and the only way forward was to rebuild it from scratch and re-import all my files.