Permission issues with Docker

metaporic · March 25, 2024, 2:24pm

Nextcloud version - 28
Operating system - OMV6 and Docker/Portainer
Is this the first time you’ve seen this error? - Yes

Hi all, sorry for the long read but I was hoping to provide as much useful information and context as possible.

So after having my Nextcloud up and running for the past year or so, I have suddenly been unable to access my container due to what seem to be permission errors. Seeing the following when visiting my containers ip.

‘Configuration was not read or initialized correctly, not overwriting /var/www/html/config/config.php’

All my files appear to be correct and in the right places, including the .ocdata file and config.php. For context, the error occurred after I installed the Nextcloud Bookmarks App (3 days ago) and Pageres via Node.js (Day of issue), which required me to enable backports on my OMV6 server as well as install the npm package manager to get working properly. I am not sure if the two are connected but shortly after this process, I noticed that I was getting the above error on trying to access my NC container. According to my logs, my container also tried to upgrade itself around that time which is odd as I successfully upgraded it last week and was using it fine since.

Reading online, it seemed most likely to be a permission issue so I ran:

exec -u www-data -it nextcloud-app-1 /bin/bash and tried to run sudo chmod -R 755 /var/www/html/data/ but bumped into an output stating permission denied and chmod -R 755 /var/www/html/ which seemed to run but gave the operation denied error.

I decided to try rsyncing over a backup from around a week ago to see if this would fix the issue but I ran into the same issue after restarting my docker and pointing it to the new location.

So I thought it would just be easier to re-deploy and re-pull the image, hoping it would overwrite whatever issue had occurred, but instead I am running into this error on trying to access my container:

///

## Error

** Your data directory is invalid.Ensure there is a file called “.ocdata” in the root of the data directory.*
** Cannot write into “config” directory.This can usually be fixed by giving the web server write access to the config directory. See Introduction — Nextcloud latest Administration Manual latest documentation. Or, if you prefer to keep config.php file read only, set the option “config_is_read_only” to true in it. See Configuration Parameters — Nextcloud latest Administration Manual latest documentation*
** 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.*
** Your data directory is not writable.Permissions can usually be fixed by giving the web server write access to the root directory. See Introduction — Nextcloud latest Administration Manual latest documentation*

///

I have also tried using occ to disable the Bookmark App in case that was the issue but am receiving this error:

///

root@redacted~# docker exec -u www-data -it nextcloud-app-1 php occ
Console has to be executed with the user that owns the file config/config.php
Current user id: 33
Owner id of config.php: 0
Try adding ‘sudo -u #0’ to the beginning of the command (without the single quotes)
If running with ‘docker exec’ try adding the option ‘-u 0’ to the docker command (without the single quotes)
*root@redacted:~# *

///

I have also tried adding PUID and PGID variables under my environment section of my Portainer stack, but this did not seem to make a difference.

Could anyone help me fix this permission issue? A lot of the information I found seems to relate to older versions of NC or alternative installs (not Docker) and I am not that familiar with user management or command line syntax. I feel like I have gotten myself a bit tangled up here tbh.

Log showing my container’s attempt to upgrade itself:

[Sun Mar 24 23:49:23.409443 2024] [mpm_prefork:notice] [pid 1] AH00170: caught SIGWINCH, shutting down gracefully
Initializing nextcloud 28.0.3.2 …
Upgrading nextcloud from 27.1.1.0 …
=> Searching for scripts (.sh) to run, located in the folder: /docker-entrypoint-hooks.d/pre-upgrade*
Nextcloud is not installed - only a limited number of commands are available

```
                                *
```
Command “upgrade” is not defined. *
```
                                *
```

=> 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 redacted… Set the ‘ServerName’ directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using redacted. Set the ‘ServerName’ directive globally to suppress this message
[Mon Mar 25 00:03:21.660939 2024] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.57 (Debian) PHP/8.2.17 configured – resuming normal operations
[Mon Mar 25 00:03:21.661083 2024] [core:notice] [pid 1] AH00094: Command line: ‘apache2 -D FOREGROUND’
redacted - redacted[25/Mar/2024:00:03:30 +0000] “POST /index.php/apps/bookmarks/public/rest/v2/lock HTTP/1.1” 503 2392 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36”
redacted - redacted [25/Mar/2024:00:03:33 +0000] “DELETE /index.php/apps/bookmarks/public/rest/v2/lock HTTP/1.1” 503 2392 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36”
redacted - redacted [25/Mar/2024:00:03:37 +0000] “POST /index.php/apps/bookmarks/public/rest/v2/lock HTTP/1.1” 503 2392 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36”
redacted - redacted [25/Mar/2024:00:03:39 +0000] “GET /index.php/204 HTTP/1.1” 503 2392 “-” “Mozilla/5.0 (Linux) mirall/3.11.0git (Nextcloud, fedora-6.7.9-100.fc38.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)”
redacted - redacted [25/Mar/2024:00:04:30 +0000] “POST /index.php/apps/bookmarks/public/rest/v2/lock HTTP/1.1” 503 2392 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36”

jtr · March 25, 2024, 8:49pm

Please post your Compose file.

From the looks of things, your mounts in the container have inappropriate ownership information. The solution will depend on how you’re mounting your volumes int your container.

If you’re bind mounting into your container this problem is more likely to crop up since permissions are easily messed up outside of Docker.

metaporic · March 26, 2024, 5:15pm

Hi Jtr, thanks for your reply, here is my Portainer Stack:

version: '2'

services:
  db:
    image: mariadb:10.5
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    volumes:
      - /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/NextcloudDB:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=redacted
      - MYSQL_PASSWORD=redacted
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - PUID=998
      - PGID=997

 app:
    image: nextcloud
    restart: always
    ports:
      - 8080:80
    links:
      - db
    volumes:
      - /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=redacted
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db
      
  cron:
    image: rcdailey/nextcloud-cronjob
    container_name: nextcloud-cron
    restart: always
    network_mode: none
    depends_on:
    - app
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock:ro
    - /etc/localtime:/etc/localtime:ro
    environment:
    - NEXTCLOUD_CONTAINER_NAME=nextcloud-app-1

wwe · March 27, 2024, 5:35pm

Please run ls -al /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud and post results. If I’m not wrong there should be

ls -al /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud/config
ls -al /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud/data
ls -al /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud/app

as well, please repeat and post results here. all this files and directories should be owned by user 33:33 (www-data on Debian-based distros).

you can fix permissions using

cd /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883
sudo chown -R www-data:www-data Nextcloud
find Nextcloud/app Nextcloud/config Nextcloud/data -type d -exec sudo chmod 750 '{}' \;
find Nextcloud/app Nextcloud/config Nextcloud/data -type f -exec sudo chmod 640 '{}' \;

metaporic · March 30, 2024, 1:34pm

Hi, wwe thanks so much for your reply!

The first command you provided seem to have addressed the issue. I have not tried running the two further commands yet as the system seems to be working and the permissions have changed to be owned by www-data rather than root. Would you still recommend running those last two commands as a precaution (a bit worried to break something)? Checking the config and data folders, they are correctly owned by www-data.

Do you know what might have caused these permissions to change? Just so I know what to look out for in the future.

Here was my output prior to running sudo chown -R www-data:www-data Nextcloud in case it is helpful for anyone else:

Permission Issue

root@redacted:/srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud# ls -al /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud
total 1236

drwxrwxrwx+ 14 root users 4096 Mar 17 00:21 .  
drwxr-sr-x 38 root users 4096 Mar 25 13:08 ..  
drwxr-sr-x 44 root users 4096 Mar 17 00:20 3rdparty  
drwxr-sr-x 50 root users 4096 Mar 17 00:20 apps  
-rw-r--r-- 1 root users 23796 Mar 17 00:20 AUTHORS  
-rw-r--r-- 1 root users 1906 Mar 17 00:20 composer.json  
-rw-r--r-- 1 root users 3140 Mar 17 00:20 composer.lock  
drwxr-sr-x 2 root users 4096 Mar 25 11:47 config  
-rw-r--r-- 1 root users 4124 Mar 17 00:20 console.php  
-rw-r--r-- 1 root users 34520 Mar 17 00:20 COPYING  
drwxr-sr-x 24 root users 4096 Mar 17 00:20 core  
-rwxr-xr-x 1 root users 6317 Mar 17 00:20 cron.php  
drwxr-sr-x 31 root users 4096 Mar 19 20:45 custom_apps  
drwxrwx---+ 6 root users 4096 Mar 14 23:45 data  
drwxr-sr-x 2 root users 20480 Mar 17 00:21 dist  
-rw-r--r-- 1 root users 5161 Mar 17 12:23 .htaccess  
-rw-r--r-- 1 root users 156 Mar 17 00:20 index.html  
-rw-r--r-- 1 root users 4403 Mar 17 00:20 index.php  
drwxr-sr-x 6 root users 4096 Mar 17 00:21 lib  
-rw-r--r-- 1 root users 0 Mar 27 14:15 nextcloud-init-sync.lock  
-rwxr-xr-x 1 root users 283 Mar 17 00:20 occ  
drwxr-sr-x 2 root users 4096 Mar 17 00:21 ocs  
drwxr-sr-x 2 root users 4096 Mar 17 00:21 ocs-provider  
-rw-r--r-- 1 root users 7072 Mar 17 00:20 package.json  
-rw-r--r-- 1 root users 1044055 Mar 17 00:20 package-lock.json  
-rw-r--r-- 1 root users 3187 Mar 17 00:20 public.php  
-rw-r--r-- 1 root users 5597 Mar 17 00:20 remote.php  
drwxr-sr-x 4 root users 4096 Mar 17 00:21 resources  
-rw-r--r-- 1 root users 26 Mar 17 00:20 robots.txt  
-rw-r--r-- 1 root users 2452 Mar 17 00:20 status.php  
drwxr-sr-x 3 root users 4096 Feb 3 2023 themes  
-rw-r--r-- 1 root users 101 Mar 17 00:20 .user.ini  
-rw-r--r-- 1 root users 403 Mar 17 00:21 version.php

Permission Fix

root@redacted: cd /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883
root@redacted:/srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883# sudo chown -R www-data:www-data Nextcloud

This seems to have fixed the issue as immediately after running that command I started receiving notifications from my container and have been able to access it normally.

I then re-ran the ‘ls’ command and this is the new output:

root@redacted:~# ls -al /srv/dev-disk-by-uuid-a914a7e5-3822-4cdb-a5e8-e8c7e3d13883/Nextcloud  
total 1236  
drwxrwxrwx+ 14 www-data www-data 4096 Mar 17 00:21 .  
drwxr-sr-x 38 root users 4096 Mar 25 13:08 ..  
drwxr-sr-x 44 www-data www-data 4096 Mar 17 00:20 3rdparty  
drwxr-sr-x 50 www-data www-data 4096 Mar 17 00:20 apps  
-rw-r--r-- 1 www-data www-data 23796 Mar 17 00:20 AUTHORS  
-rw-r--r-- 1 www-data www-data 1906 Mar 17 00:20 composer.json  
-rw-r--r-- 1 www-data www-data 3140 Mar 17 00:20 composer.lock  
drwxr-s--- 2 www-data www-data 4096 Mar 25 11:47 config  
-rw-r--r-- 1 www-data www-data 4124 Mar 17 00:20 console.php  
-rw-r--r-- 1 www-data www-data 34520 Mar 17 00:20 COPYING  
drwxr-sr-x 24 www-data www-data 4096 Mar 17 00:20 core  
-rwxr-xr-x 1 www-data www-data 6317 Mar 17 00:20 cron.php  
drwxr-sr-x 31 www-data www-data 4096 Mar 27 21:18 custom_apps  
drwxr-x---+ 6 www-data www-data 4096 Mar 14 23:45 data  
drwxr-sr-x 2 www-data www-data 20480 Mar 17 00:21 dist  
-rw-r--r-- 1 www-data www-data 5161 Mar 17 12:23 .htaccess  
-rw-r--r-- 1 www-data www-data 156 Mar 17 00:20 index.html  
-rw-r--r-- 1 www-data www-data 4403 Mar 17 00:20 index.php  
drwxr-sr-x 6 www-data www-data 4096 Mar 17 00:21 lib  
-rw-r--r-- 1 www-data www-data 0 Mar 27 14:15 nextcloud-init-sync.lock  
-rwxr-xr-x 1 www-data www-data 283 Mar 17 00:20 occ  
drwxr-sr-x 2 www-data www-data 4096 Mar 17 00:21 ocs  
drwxr-sr-x 2 www-data www-data 4096 Mar 17 00:21 ocs-provider  
-rw-r--r-- 1 www-data www-data 7072 Mar 17 00:20 package.json  
-rw-r--r-- 1 www-data www-data 1044055 Mar 17 00:20 package-lock.json  
-rw-r--r-- 1 www-data www-data 3187 Mar 17 00:20 public.php  
-rw-r--r-- 1 www-data www-data 5597 Mar 17 00:20 remote.php  
drwxr-sr-x 4 www-data www-data 4096 Mar 17 00:21 resources  
-rw-r--r-- 1 www-data www-data 26 Mar 17 00:20 robots.txt  
-rw-r--r-- 1 www-data www-data 2452 Mar 17 00:20 status.php  
drwxr-sr-x 3 www-data www-data 4096 Feb 3 2023 themes  
-rw-r--r-- 1 www-data www-data 101 Mar 17 00:20 .user.ini  
-rw-r--r-- 1 www-data www-data 403 Mar 17 00:21 version.php

wwe · March 30, 2024, 8:31pm

-rw-r–r-- is basically 640 which is right permission for files
drwxr-xr-x is 750 which is right for directories

which both are OK the 2nd and 3rd command would configure such permissions. From your listing top-level permissions look good. I would still run the remaining command to ensure correct permissions applied on lower lever files and folders as well.

no idea - I didn’t hit such issues without a reason for 5 years - you should remember what you did short before… maybe copy maybe mount the volumes to another container…

system · April 7, 2024, 8:31pm

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