Upgrade using docker compose leads to "Cannot write into "apps" directory" error

Hi all,

i recently installed nextcloud on my raspberry pi 5 following chrisbeardy’s tutorial on github.

Docker is installed using the following docker-compose.yaml:

version: '3'

volumes:
  nextcloud-data:
  nextcloud-db:

networks:
  frontend:
    external:
      name: proxy
  backend:

services:

  nextcloud-app:
    image: nextcloud
    restart: always
    volumes:
      - nextcloud-data:/var/www/html
    environment:
      - MYSQL_PASSWORD=REDACTED
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=nextcloud-db
      - PHP_UPLOAD_LIMIT=10G
      - PHP_MEMORY_LIMIT=512M
    networks:
      - frontend
      - backend

  nextcloud-db:
    image: mariadb
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --innodb-file-per-table=1 --skip-innodb-read-only-compressed
    volumes:
      - nextcloud-db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=REDACTED
      - MYSQL_PASSWORD=REDACTED
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    networks:
      - backend

Everything was running fine for approximately 2 months until today i decided to try updating nextcloud to the newest version.

So following the nextcloud docker github documentation i ssh’d to my raspberry entered the nextcloud directory (where the afformentioned docker-compose.yml resides) and ran

docker compose pull
docker compose up -d

watching docker compose do the work and thinking to myself "well this is very nice and easy - i wonder why i didn’t try to update sooner.

So after docker compose finished without errors, i excitedly opened my nextcloud url (schlichcloud.goip.de) and somewhat disapointed find an error message telling me that an update is required and that i should run the command line updater.

Well a minor mishap - i somewhat naively think to myself - and off i go to ask doctor google how to run the command line interpreter. A little while later i ran

docker exec --user www-data -it nextcloud-nextcloud-app-1 bash
/usr/src/nextcloud/occ upgrade -v

Okay, easy enough, i guess - but oh no:

Cannot write into "config" directory.
This can usually be fixed by giving the web server write access to the configs directory.

So i exit docker exec and reenter as root using chown to transfer ownership of /var/www/html/config/ to user www-data, exited and reenter docker exec as www-data and tried to run /usr/src/nextcloud/occ upgrade -v again. But now it gives me another error:

Nextcloud is not installed - only a limited number of commands are available
Cannot write into "apps" directory.
This can usually be fixed by giving the web server write access to the apps directory or disabling the App Store in the config file.

An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /usr/src/nextcloud/lib/private/Console/Application.php:137
Stack trace:
#0 /usr/src/nextcloud/console.php(81): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#1 /usr/src/nextcloud/occ(11): require_once('/usr/src/nextcl...')

So i reentered docker exec as root, thinking "well okay, i’m just gonna chown /var/www/html/apps/ to user ẁww-data. But to my surprise it was allready owned by ẁww-data.

I have been googling potential solutens for the past hour and a half or so and am out of my wits.

Any help would be greatly appreaciated.

The image handles the upgrade itself. The place to look to see what originally happened would be your container logs from this time period.

That said, you’re using Docker managed volumes. The permissions are not something you should have to mess with here. The permissions of your volumes are Docker managed. Not sure what’s going on here.

You said you changed the ownership of config/… Do you know what owner was shown prior to changing it? That may provide some hints about what is going on here.

/usr/src/nextcloud/occ upgrade -v

Please use the installer occ not the one from this directory. GitHub - nextcloud/docker: ⛴ Docker image of Nextcloud

1 Like

Hey, thanks for the input and for the tip on running occ on docker - this nextcloud installation is actually the first and only time i’ve used docker, so i’m taking this as a huge opportunity to learn and expand my horizon. And sorry for the late reply - it was a busy weekend and i only just now found time to sit down in front of my computer again.

I was not expecting to have to mess with permissions when i started the upgrade myself - but here i am :wink: …

However - following your leads, the permissions do not seem to be the problem:

Prior to me chowning the config/ to www-data it was owned by root which did not appear mysterious to me.

The logs of the docker container:

Initializing nextcloud 30.0.6.2 ...
Upgrading nextcloud from 30.0.2.2 ...
=> Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/pre-upgrade
An unhandled exception has been thrown:
Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2002] Connection refused in /var/www/html/lib/private/DB/Connection.php:233
Stack trace:
#0 /var/www/html/3rdparty/doctrine/dbal/src/Connection.php(458): OC\DB\Connection->connect()
#1 /var/www/html/3rdparty/doctrine/dbal/src/Connection.php(416): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /var/www/html/3rdparty/doctrine/dbal/src/Connection.php(323): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /var/www/html/lib/private/DB/Connection.php(899): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /var/www/html/lib/private/DB/ConnectionAdapter.php(235): OC\DB\Connection->getDatabaseProvider()
#5 /var/www/html/lib/private/DB/QueryBuilder/QueryBuilder.php(96): OC\DB\ConnectionAdapter->getDatabaseProvider()
#6 /var/www/html/lib/private/AppConfig.php(1211): OC\DB\QueryBuilder\QueryBuilder->expr()
#7 /var/www/html/lib/private/AppConfig.php(237): OC\AppConfig->loadConfig(false)
#8 /var/www/html/lib/private/AppConfig.php(1351): OC\AppConfig->searchValues('enabled', false, 2)
#9 /var/www/html/lib/private/App/AppManager.php(126): OC\AppConfig->getValues(false, 'enabled')
#10 /var/www/html/lib/private/App/AppManager.php(147): OC\App\AppManager->getInstalledAppsValues()
#11 /var/www/html/lib/private/legacy/OC_App.php(191): OC\App\AppManager->getInstalledApps()
#12 /var/www/html/lib/private/AppFramework/Bootstrap/Coordinator.php(48): OC_App::getEnabledApps()
#13 /var/www/html/lib/base.php(659): OC\AppFramework\Bootstrap\Coordinator->runInitialRegistration()
#14 /var/www/html/lib/base.php(1134): OC::init()
#15 /var/www/html/console.php(28): require_once('/var/www/html/l...')
#16 /var/www/html/occ(11): require_once('/var/www/html/c...')
#17 {main}Warning: /var/www/html/config/redis.config.php differs from the latest version of this image at /usr/src/nextcloud/config/redis.config.php
=> Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/before-starting
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.3. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.3. Set the 'ServerName' directive globally to suppress this message
[Sat Feb 15 04:01:00.987770 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) PHP/8.2.27 configured -- resuming normal operations
[Sat Feb 15 04:01:00.987841 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

indicate nextcloud could not connect to the database, which i find extremely odd, because it was running without problems before the update and i did not change the docker-compose.yaml. (Everything following the lines above is just a bunch of GET-requests).

Running docker ps reveals, the database is up and running and started together with the nextcloud app when i ran the docker compose up -d command.

ce63284d6ee2   nextcloud                                            "/entrypoint.sh apac…"   39 hours ago   Up 39 hours           80/tcp                                                                                           nextcloud-nextcloud-app-1
13ef93e81d81   mariadb                                              "docker-entrypoint.s…"   39 hours ago   Up 39 hours           3306/tcp                                                                                         nextcloud-nextcloud-db-1

The logs of the database container do not appear to indicate anything wrong with the databse as far as i can tell:

2025-02-15 04:00:56+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.6.2+maria~ubu2404 started.
2025-02-15 04:00:56+00:00 [Warn] [Entrypoint]: /sys/fs/cgroup///memory.pressure not writable, functionality unavailable to MariaDB
2025-02-15 04:00:56+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2025-02-15 04:00:56+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.6.2+maria~ubu2404 started.
2025-02-15 04:00:57+00:00 [Note] [Entrypoint]: MariaDB upgrade (mariadb-upgrade or creating healthcheck users) required, but skipped due to $MARIADB_AUTO_UPGRADE setting
2025-02-15  4:00:57 0 [Note] Starting MariaDB 11.6.2-MariaDB-ubu2404 source revision d8dad8c3b54cd09fefce7bc3b9749f427eed9709 server_uid 72+4ASMvYxproTQgRqIDplDA1XA= as process 1
2025-02-15  4:00:57 0 [Warning] --innodb-file-per-table is deprecated and will be removed in a future release
2025-02-15  4:00:57 0 [Note] InnoDB: Compressed tables use zlib 1.3
2025-02-15  4:00:57 0 [Note] InnoDB: Number of transaction pools: 1
2025-02-15  4:00:57 0 [Note] InnoDB: Using ARMv8 crc32 + pmull instructions
2025-02-15  4:00:57 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
2025-02-15  4:00:57 0 [Note] InnoDB: Using liburing
2025-02-15  4:00:57 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2025-02-15  4:00:57 0 [Note] InnoDB: Completed initialization of buffer pool
2025-02-15  4:00:57 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
2025-02-15  4:00:57 0 [Note] InnoDB: End of log at LSN=3800378875
2025-02-15  4:00:57 0 [Note] InnoDB: Opened 3 undo tablespaces
2025-02-15  4:00:57 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
2025-02-15  4:00:57 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2025-02-15  4:00:57 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2025-02-15  4:00:57 0 [Note] InnoDB: log sequence number 3800378875; transaction id 15415129
2025-02-15  4:00:57 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2025-02-15  4:00:57 0 [Note] Plugin 'FEEDBACK' is disabled.
2025-02-15  4:00:57 0 [Note] Plugin 'wsrep-provider' is disabled.
2025-02-15  4:00:57 0 [Note] InnoDB: Buffer pool(s) load completed at 250215  4:00:57
2025-02-15  4:01:00 0 [Note] Server socket created on IP: '0.0.0.0'.
2025-02-15  4:01:00 0 [Note] Server socket created on IP: '::'.
2025-02-15  4:01:00 0 [Note] mariadbd: Event Scheduler: Loaded 0 events
2025-02-15  4:01:00 0 [Note] mariadbd: ready for connections.
Version: '11.6.2-MariaDB-ubu2404'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution

Any idea where to go from here?

Happy to report, the issue has been resolved.

That should have been the first thing i tried, but i somehow missed the forrest for all the trees there. However i was about to report an issue on the nextcloud docker image github page and in preparation to that i pulled the occ config:list system using occ as jtr suggested… And then i finally got the idea to try upgrading again, this time using occ via docker exec --user www-data CONTAINER_ID php occ and it worked like a charm.

Other than that, docker exec ... occ reported 2 minor issues in my docker-compose.yaml which lead me to remove

version: '3'

and rewrite

networks:
  frontend:
    external:
      name: proxy
  backend:

to

networks:
  frontend:
    external:
      name: proxy
      external: true

but i doubt that was the issue.

Thank you very much jtr! I can finally privately sync all my stuff again and got to learn a little bit about basic docker usage along the way. :smiley: It really is greatly appreciated!

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.