Nextcloud version (eg, 20.0.5): 23.0.0 (official docker image)
Operating system and version (eg, Ubuntu 20.04): Debian 10
Apache or nginx version (eg, Apache 2.4.25): Standard docker image
PHP version (eg, 7.4): Standard docker image
The issue you are facing:
Background
I have been on a journey to migrate my Nextcloud installation between servers. I’ll spare the majority of the background, because it appears to be resolved. Everything, however, related to permissions. Something about the 23 docker image was not playing nicely. As background, I installed the image a few times, adding options as I went, and deleting everything (including persistent storage) each time. I did this on purpose, as I was trying to optimize settings, and then a few more times as I was trying to troubleshoot the permissions issues. Eventually, however, I got the instance running, the files:scan executed, etc. Note that the previous instance I am migrating from is also 23.0.0, but was installed a long time ago and updated to 23, so … maybe a NC23 issue here?
Current issues
Still experiencing what appears to be significant permissions issues, however. Mostly it’s manifesting in “unable to…” popups whenever I load settings screens. For example:
- “Unable to retrieve the group list” on Basic Settings
- Working hours will not save (failure to save is silent)
- “Error loading information about shares” on Privacy
- “Error loading additional administrator” on Privacy
- cron is not running
- “Problem loading page” on Sharing
- “Unable to retrieve group list” on Sharing
- Changes to notifications apparently not saving on Activity
Etc. etc. Also the Apps screen isn’t loading at all.
Steps to replicate it:
- Login
- Click around settings
- Watch error popups and silently failing permissions changes
The output of your Nextcloud log in Admin > Logging:
This isn't showing up either...
The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):
$CONFIG = array (
'overwriteprotocol' => 'https',
'htaccess.RewriteBase' => '/',
'memcache.local' => '\\OC\\Memcache\\APCu',
'apps_paths' =>
array (
0 =>
array (
'path' => '/var/www/html/apps',
'url' => '/apps',
'writable' => false,
),
1 =>
array (
'path' => '/var/www/html/custom_apps',
'url' => '/custom_apps',
'writable' => true,
),
),
'instanceid' => '****',
'passwordsalt' => '****',
'secret' => '****',
'trusted_domains' =>
array (
0 => '****',
1 => '****',
),
'datadirectory' => '/var/www/html/data',
'dbtype' => 'mysql',
'version' => '23.0.0.10',
'overwrite.cli.url' => '****',
'dbname' => 'nextcloud',
'dbhost' => 'mariadb-db',
'dbport' => '',
'dbtableprefix' => 'oc_',
'mysql.utf8mb4' => true,
'dbuser' => '****',
'dbpassword' => '****',
'installed' => true,
'default_phone_region' => 'US',
'maintenance' => false,
'mail_smtpmode' => 'smtp',
'mail_smtpsecure' => 'ssl',
'mail_sendmailmode' => 'smtp',
'mail_from_address' => 'admin',
'mail_domain' => '****',
'mail_smtpauthtype' => 'LOGIN',
'mail_smtpauth' => 1,
'mail_smtphost' => '****',
'mail_smtpport' => '465',
'mail_smtpname' => '****',
'mail_smtppassword' => '****',
);
The output of your Apache/nginx/system log in /var/log/____:
Within the container, /var/log/apache2 are all linked to system logs
Within the host, there is no apache/nginx log
Permissions (WITHIN the container):
/var/www
drwxr-xr-x 14 www-data root 4096 Jan 9 17:35 html
/var/www/html
drwxr-xr-x 14 www-data root 4096 Jan 9 17:35 .
drwxrwxr-x 1 www-data root 4096 Jan 9 17:51 ..
-rw-r--r-- 1 www-data root 4338 Jan 9 17:47 .htaccess
-rw-r--r-- 1 www-data root 101 Jan 9 17:35 .user.ini
drwxr-xr-x 44 www-data root 4096 Jan 9 17:35 3rdparty
-rw-r--r-- 1 www-data root 19327 Jan 9 17:35 AUTHORS
-rw-r--r-- 1 www-data root 34520 Jan 9 17:35 COPYING
drwxr-xr-x 48 www-data root 4096 Jan 9 17:35 apps
drwxr-x--- 2 www-data www-data 4096 Jan 10 02:06 config
-rw-r--r-- 1 www-data root 3924 Jan 9 17:35 console.php
drwxr-xr-x 22 www-data root 4096 Jan 9 17:35 core
-rw-r--r-- 1 www-data root 5226 Jan 9 17:35 cron.php
drwxr-xr-x 10 www-data root 4096 Jan 10 00:54 custom_apps
drwxrwx--- 5 www-data root 4096 Jan 9 17:49 data
-rw-r--r-- 1 www-data root 156 Jan 9 17:35 index.html
-rw-r--r-- 1 www-data root 3455 Jan 9 17:35 index.php
drwxr-xr-x 6 www-data root 4096 Jan 9 17:35 lib
-rwxr-xr-x 1 www-data root 283 Jan 9 17:35 occ
drwxr-xr-x 2 www-data root 4096 Jan 9 17:35 ocm-provider
drwxr-xr-x 2 www-data root 4096 Jan 9 17:35 ocs
drwxr-xr-x 2 www-data root 4096 Jan 9 17:35 ocs-provider
-rw-r--r-- 1 www-data root 3139 Jan 9 17:35 public.php
-rw-r--r-- 1 www-data root 5340 Jan 9 17:35 remote.php
drwxr-xr-x 4 www-data root 4096 Jan 9 17:35 resources
-rw-r--r-- 1 www-data root 26 Jan 9 17:35 robots.txt
-rw-r--r-- 1 www-data root 2452 Jan 9 17:35 status.php
drwxr-xr-x 3 www-data root 4096 Jan 9 17:35 themes
-rw-r--r-- 1 www-data root 383 Jan 9 17:35 version.php
Before a do a bulk chown to www-data:www-data, would that cause the issues I’m seeing? And why would that issue arise with the standard docker image? (I didn’t change anything related to permissions, other than chgrp the config directory while troubleshooting.)