After upgrading to 10.5 I'm getting config write error

Server
1

Steps to reproduce

Try to use any client to connect to the server.

Expected behaviour

Well, it should work.

Actual behaviour

I’m getting message that system can’t write to the config.

Server configuration

Operating system: Arch Linux

Web server: Apache/2.4.46 with php-fpm

Database: MariaDB 10.4.13

PHP version: 7.4.11

ownCloud version: 10.5.0

Updated from an older ownCloud or fresh install: Update from 10.3

Where did you install ownCloud from: Manually

Signing status (ownCloud 9.0 and above):
Don’t know what it is, can’t log in even to try and see.

The content of config/config.php:

{
    "system": {
        "instanceid": "oc11a7lsh7wt",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "10.5.0.10",
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "UTC",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "tls",
        "mail_smtpauthtype": "PLAIN",
        "mail_smtpauth": 1,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "redis": {
            "host": "localhost",
            "port": 6379
        },
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "theme": "",
        "loglevel": 0,
        "log_type": "owncloud",
        "debug": true,
        "maintenance": false,
        "htaccess.RewriteBase": "\/",
        "updater.secret": "***REMOVED SENSITIVE VALUE***",
        "upgrade.automatic-app-update": true
    }
}

List of activated apps:

Enabled:
  - comments: 0.3.0
  - configreport: 0.2.0
  - dav: 0.6.0
  - federatedfilesharing: 0.5.0
  - federation: 0.1.0
  - files: 1.5.2
  - files_external: 0.7.1
  - files_mediaviewer: 1.0.3
  - files_sharing: 0.13.0
  - files_texteditor: 2.3.0
  - files_trashbin: 0.9.1
  - files_versions: 1.3.0
  - firstrunwizard: 1.2.0
  - market: 0.6.0
  - notifications: 0.5.2
  - provisioning_api: 0.5.0
  - templateeditor: 0.4.0
  - twofactor_totp: 0.7.0
  - updatenotification: 0.2.1

Disabled:
  - activity
  - admin_audit
  - announcementcenter
  - camerarawpreviews
  - customgroups
  - encryption
  - enterprise_key
  - external
  - files_antivirus
  - files_classifier
  - files_external_dropbox
  - files_external_ftp
  - files_ldap_home
  - files_pdfviewer
  - firewall
  - gallery
  - gpxpod
  - guests
  - oauth2
  - password_policy
  - ransomware_protection
  - sharepoint
  - systemtags
  - systemtags_management
  - theme-enterprise
  - user_external
  - user_ldap
  - user_shibboleth
  - windows_network_drive
  - wopi
  - workflow

Are you using external storage, if yes which one: Nope

Are you using encryption: no

Are you using an external user-backend, if yes which one: Nope

Client configuration

Browser: Firefox 82.0b9

Operating system: Windows 10

Logs

Web server error log

Nothing in the logs

ownCloud log (data/owncloud.log)

Nothing in the logs

Browser log

Nothing in the logs

Updated from 10.3 and I did that like before - by manualy downloading package and replacing everything with the upgrade guide providing me with steps. But this time I can’t access the server from any client (web also) because system gives me info about permission issue with writing to config. I checked all the folders for both ownership and permission mask and it’s exactly the same as it was before - server owns it:

drwxr-xr-x 12 http http   4096 08-03 09:20 .
drwxr-xr-x  7 root root   4096 10-12 22:26 ..
-rw-r--r--  1 http http   4599 10-12 22:35 .htaccess
-rw-r--r--  1 http http    163 08-03 09:20 .user.ini
-rw-r--r--  1 http http   8859 08-03 09:20 AUTHORS
-rw-r--r--  1 http http 234862 08-03 09:20 CHANGELOG.md
-rw-r--r--  1 http http  34520 08-03 09:20 COPYING
-rw-r--r--  1 http http   2157 08-03 09:20 README.md
drwxrwxrwx 52 http http   4096 10-12 22:34 apps
drwxrwxrwx  2 http http   4096 10-12 22:29 config
-rw-r--r--  1 http http   4624 08-03 09:20 console.php
drwxr-xr-x 16 http http   4096 08-03 09:21 core
-rw-r--r--  1 http http   1717 08-03 09:20 cron.php
-rw-r--r--  1 http http  31204 08-03 09:20 db_structure.xml
-rw-r--r--  1 http http    179 08-03 09:20 index.html
-rw-r--r--  1 http http   3524 08-03 09:20 index.php
drwxr-xr-x  6 http http   4096 08-03 09:20 lib
-rwxr-xr-x  1 http http    283 08-03 09:20 occ
drwxr-xr-x  2 http http   4096 08-03 09:20 ocm-provider
drwxr-xr-x  2 http http   4096 08-03 09:20 ocs
drwxr-xr-x  2 http http   4096 08-03 09:20 ocs-provider
-rw-r--r--  1 http http   3135 08-03 09:20 public.php
-rw-r--r--  1 http http   5618 08-03 09:20 remote.php
drwxr-xr-x  4 http http   4096 08-03 09:20 resources
-rw-r--r--  1 http http     26 08-03 09:20 robots.txt
drwxr-xr-x 12 http http   4096 08-03 09:20 settings
-rw-r--r--  1 http http   2231 08-03 09:20 status.php
drwxr-xr-x  6 http http   4096 2019-11-14  updater
-rw-r--r--  1 http http    281 08-03 09:20 version.php

I also have open_basedir setup through php-fpm config file to include owncloud install folder. The only thing that I did change was finally moving instance to the PHP 7.4 instead of 7.3 at which it worked before. Upgrade process went fine, without any errors. occ check also doesn’t output anything. What’s weird for me is that there’s nothing in any error logs, whatever log level is set to. Access log gives info about entering site but that’s it.

I’ve already tried to sudo -u http ls -la owncloud/config to see if the webserver user has access…and it has. I tried to even edit config file this way and it worked without issue.

Do you have any tips what I could do to debug this? I’ve already tried setting new version twice.

2

You’re saying your running PHP-FPM, as which user are you running this. As it might not be running as the user ‘http’ and therefore not have write access to the ownCloud folder.

1 Like
3

Good point, forgot to mention that php-fpm is set to work with the same user as Apache:

user = http
group = http
listen.owner = http
listen.group = http
listen.mode = 0660

Which I did confirm looking at process list.
Do remember that this config worked before without any issues. And the config for php7.4 and php7.3 is basically the same.

4

I think that is much more likely the culprit than the upgrade of ownCloud itself, make sure you configured your new PHP installation exactly the same as the old one.

1 Like
5

PHP 7.4 is not new here actually. I’m using it for quite long time and had to have 7.3 only for the owncloud instance.
I’m pretty sure it’s some config issue but because I don’t any logs entries I have no idea where to look. And like I said both PHP version are basically the same in terms of configuration. The difference comes down to paths to extensions (for example extension_dir = "/usr/lib/php/modules/" vs extension_dir = "/usr/lib/php73/modules/") and .pid .sock for php-fpm.
Maybe there is something in 10.5 branch vs 10.3 that needs change in PHP/Apache that relates to permissions?

6

What you’re advertising as content of config/config.php is not quite how I am usually used to it being formatted, is that just because you had to edit out the confidential stuff and it is otherwise an exact copy of your config.php?

Are there other files in your config/ folder?

Can you provide a configreport?

What is the output of occ status?

1 Like
7

Hm…That is the report from the provided tool so I’m not sure where is the problem. The only thing I did was obscuring domain and path. Looking at the link you gave me I also did only system output, as was described in the template here.
Anyway occ status:

  - installed: true
  - first_install_version: unknown
  - version: 10.5.0.10
  - versionstring: 10.5.0
  - edition: Community

As for the config I did generate it again. This time full version.
own-config.txt (304.2 KB)

1 Like
8

Hmm, OK, I had a look through your configreport, and it doesn’t seem like there is anything set within ownCloud that would restrict access to the config.php.

Can you please paste the output of ls -alZ /path/to/your/owncloud/config/ ?
Similarly of: pgrep -fau http
SELinux or something like that running?

1 Like
9

There’s no SELinux or anything like that…at least I can’t think of anything that would prevent access on system level.

drwxrwxrwx  2 http http ?  4096 10-12 22:29 .
drwxr-xr-x 12 http http ?  4096 08-03 09:20 ..
-rw-r--r--  1 http http ?  5229 08-03 09:20 config.apps.sample.php
-rw-r-----  1 http http ?  1270 10-12 22:45 config.php
-rw-r--r--  1 http http ? 53123 08-03 09:20 config.sample.php

As for the processes - this is the list that is related to the owncloud:

2054417 /usr/bin/httpd -k start -DFOREGROUND
2054418 /usr/bin/httpd -k start -DFOREGROUND
2054419 /usr/bin/httpd -k start -DFOREGROUND
2054634 /usr/bin/httpd -k start -DFOREGROUND
2054911 php-fpm: pool owncloud
2054912 php-fpm: pool owncloud
2054913 php-fpm: pool owncloud
2054914 php-fpm: pool owncloud
2054915 php-fpm: pool owncloud
2054916 php-fpm: pool owncloud

I’ve made a simple test:

var_dump(is_readable('/usr/share/webapps/owncloud/config/'));
var_dump(is_readable('/usr/share/webapps/owncloud/config/config.php'));
var_dump(is_writable('/usr/share/webapps/owncloud/config/'));
var_dump(is_writable('/usr/share/webapps/owncloud/config/config.php'));
exit;

I put it in the index.php and the results were as expected: true, true, false, false
I did also try to make config.php writable by everyone to check if the system could write to it then but still it fails.
What is weird is that when I tried to run this with: sudo -u http php index.php or simply php index.php I got four true in the console. What is even more weird is that the latter is invoked by currently logged user that, when tried with nano, can’t actually edit the file.

10

Have you tried adjusting it? Giving the group write access as well?
Are you perhaps constricting the PHP pool in the systemd service definition?
Additionall file system attributes (chattr)?

Can you switch back to PHP7.3 and does it start working again if you do?

1 Like
11

Yes, I did. I gave 0777 for a moment and 0775 as well. Didn’t help at all.
How I would constrain PHP this way? You mean like in chroot? If that’s what you meant then no, it’s not.
Not sure what should I change with chattr.

Yes, I can switch. And yes, it works then. Which is the thing I don’t get the most as difference in config between both versions (php.ini and php-fpm pool) is really path to extensions…I really lost ideas where to check that…

12

There are a lot of options in the systemd service files that can basically chroot a process, make sure that the systemd configuration between the two PHP versions is the same.

I just wanted you to make sure that you don’t have additional file system attributes in place, like for example the immutable flag (though then you wouldn’t be able to edit at all…)

2 Likes
13

Oh, I thought you meant config for the php-fpm and the pool. I didn’t think about checking service files and from what I see there is a difference between them. There’s a bunch of protecting variables there and now I finally found the culprit here: ProtectSystem that needs to be set to false in order it to work. Thanks for your suggestions!

PHP73

[Unit]
Description=The PHP FastCGI Process Manager
After=network.target

[Service]
Type=notify
PIDFile=/run/php73-fpm/php-fpm.pid
ExecStart=/usr/bin/php-fpm73 --nodaemonize --fpm-config /etc/php73/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

PHP74

[Unit]
Description=The PHP FastCGI Process Manager
After=network.target

[Service]
Type=notify
PIDFile=/run/php-fpm/php-fpm.pid
ExecStart=/usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID

# Set up a new file system namespace and mounts private /tmp and /var/tmp directories
# so this service cannot access the global directories and other processes cannot
# access this service's directories.
PrivateTmp=true

# Mounts the /usr, /boot, and /etc directories read-only for processes invoked by this unit.
ProtectSystem=full

# Sets up a new /dev namespace for the executed processes and only adds API pseudo devices
# such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it,
# but no physical devices such as /dev/sda.
PrivateDevices=true

# Explicit module loading will be denied. This allows to turn off module load and unload
# operations on modular kernels. It is recommended to turn this on for most services that
# do not need special file systems or extra kernel modules to work.
ProtectKernelModules=true

# Kernel variables accessible through /proc/sys, /sys, /proc/sysrq-trigger, /proc/latency_stats,
# /proc/acpi, /proc/timer_stats, /proc/fs and /proc/irq will be made read-only to all processes
# of the unit. Usually, tunable kernel variables should only be written at boot-time, with the
# sysctl.d(5) mechanism. Almost no services need to write to these at runtime; it is hence
# recommended to turn this on for most services.
ProtectKernelTunables=true

# The Linux Control Groups (cgroups(7)) hierarchies accessible through /sys/fs/cgroup will be
# made read-only to all processes of the unit. Except for container managers no services should
# require write access to the control groups hierarchies; it is hence recommended to turn this on
# for most services
ProtectControlGroups=true

# Any attempts to enable realtime scheduling in a process of the unit are refused.
RestrictRealtime=true

# Restricts the set of socket address families accessible to the processes of this unit.
# Protects against vulnerabilities such as CVE-2016-8655
RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX

# Takes away the ability to create or manage any kind of namespace
RestrictNamespaces=true

[Install]
WantedBy=multi-user.target
2 Likes