Nextcloud 21 Upgrade: Cannot write into "config" directory!

Note: There is another thread on this forum about the latest Nextcloud upgrade but I decided to create a separate one since I am not sure if these two problems are related.

I was running a Apache Server with Nextcloud on a Manjaro (Arch Linux) distribution. The last Upgrade to Nextcloud 21 introduced major changes such as implementing php v8 and a new user “nextcloud” to run the app.

After the upgrade I get an Error on the server page: Cannot write into “config” directory!

Obviously I made sure the new nextcloud user is the owner of both the config directory the data directory and the writeable apps directory as the Arch Wiki Page suggests.

A few things I found out:

  • config.php has permissions 644. If I change that to something more lenient, e.g. 777, I get additional errors (Cannot write into “apps” and data directory)
  • occcommands terminate with PHP Fatal error: Allowed memory size exhausted in /usr/share/webapps/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php on line 133. If I allow an unlimited amount of memory, the process gets killed after a few seconds.
  • Setting 'installed' => false in the config.php changes the occ behavior to output Nextcloud is not installed … but only if I use the binary in /usr/bin/. If I use the occ binary inside the directory ./occ the output is again Cannot write into “config” directory! in the command line.

I am by no means an expert in this and I ran out of ideas. Any suggestions on how to proceed would be much appreciated!

TL;DR: All relevant directories need write permissions for both the new user “nextcloud” and the user “http”.

After a while I concluded that my setup is broken beyond repair. So I installed Manjaro from scratch, configured a LAMP server, which is working, installed the Nextcloud package and …

Internal Server Error

but at least the php memory errors didn’t show up anymore.

However just by pure coincidence I found out about a setup which works. The introduction of the new “nextcloud” user has left this weird situation where both the http user and the nextcloud user need to have write access to the relevant directories.

E.g. the config directories permissions are correct when user=nextcloud group=http and permissions are 775. The config.php on the other hand works with 660. Here’s the catch: Nextcloud overwrites the file’s permissions back to 640 when maintenance mode is turned on for example. The other directories apps, and data also need wirte permissions both for nextcloud and http user.

My way around this is atm to run apache as user nextcloud.
No idea if it is a good idea, pretty sure it might not be, but it seems to work:
Edit /etc/httpd/conf/httpd.conf
and look for User and do:
User nextcloud
Group nextcloud
#User http
#Group http

Since it is easy to undo it, you can try it.

I finally got it working reliably by setting up a systemd timer executing a script at boot and, just to make sure, every 5 minutes afterwards, that does a chmod -R http:nextcloud and a chown -fR 770 on:
/var/lib/nextcloud
/etc/webapps/nextcloud/config
/usr/share/webapps/nextcloud
Maybe the 770 is overkill for some of the files, but I am in no mood to finetune any longer.

The message complaining about Imagick beeing compiled against a different version (happens to me whenever I use occ), can be suppressed by adding imagick.skip_version_check = 1 to php.ini, if one feels the need to do so. I didn’t.

The Warning no app in context "Invalid data provided to provideInitialState by files" everytime a user opens the files app can be overcome by going into the files app and clicking the + icon then creating a new file and selecting “Set up Templates Folder”. Has to be done for every user. Again, if one feels the need to do so. I didn’t, because I don’t need or want that folder there.

There are still more error messages in the log (I guess because of php8), but I hope they will be ironed out within the next releases of Nextcloud.

All in all upgrading Nextloud 20 to 21 in combination with php8 and the new user nexctloud was just a horrible experience for a pure hobbyist, like myself. Should have listened to my own advice I gave in another thread and should have used docker…

This could be cone better.
chown -R nextcloud:nextcloud and usermod -a -G nextcloud http. That will add the Group nextcloud to the user http and chmod 770 will make all files readable/writeable/executeable to all user in group nextcloud.
The way I am doing it right now, and that seems to work, is to run httpd as a different user.
In /etc/httpd/conf/httpd.conf
You can change what user apache runs as:
User nextcloud
Group nextcloud
#User http
#Group http
That seems to work, but it is also not pretty and it might lead to even more problems if you run more than just nextcloud.
But I totally agree that the user nextcloud is a pain and the update was a rushed.

1 Like

As I am running three services, I will leave it the way, I configured it, for now.
When I am in the mood to tinker again, I will try it your way. Seems to be more elegant.
Thanks for the explaination @Kessl

What exactly do you mean? Is it as follows:

usermod -a -G nextcloud http  

chown -R nextcloud:nextcloud /var/lib/nextcloud
chown -R nextcloud:nextcloud /etc/webapps/nextcloud/config
chown -R nextcloud:nextcloud /usr/share/webapps/nextcloud

chmod 770 /var/lib/nextcloud
chmod 770 /etc/webapps/nextcloud/config
chmod 770 /usr/share/webapps/nextcloud

If so, I run into

Writing to the "apps" directory is not possible. This can usually be fixed by giving the web server write access to the app directory or disabling the App Store in the configuration file.

What do you propose?

Keep in mind a lot of tips and best practices on moving to v21 can be found at
https://wiki.archlinux.org/index.php/Nextcloud

In the arch-wiki nextcloud the apps-paths is configured in “Writable apps directory”.

                'path'=> '/usr/share/webapps/nextcloud/apps',

At my server it is writable for the nextcloud and every user user in the same group:

drwxrwxrwx 47 nextcloud nextcloud 4096 15. Mär 18:37 .
drwxrwx--- 12 nextcloud nextcloud 4096 15. Mär 18:37 ..
drwxrwxr-x 11 nextcloud nextcloud 4096 15. Mär 18:37 accessibility
drwxrwxr-x 10 nextcloud nextcloud 4096 15. Mär 18:37 activity
d
...

??

How does your config.php look like?
Are both /usr/share/webapps/nextcloud/apps (apps) and/var/lib/nextcloud/apps (wapps) configured correctly ('writable' => false, and 'writable' => true,)?

Yes, they are configured:

  'apps_paths' => array (
        0 => array (
                'path' => '/usr/share/webapps/nextcloud/apps',
                'url' => '/apps',
                'writable' => false,
        ),
        1 => array (
                'path' => '/var/lib/nextcloud/apps',
                'url' => '/wapps',
                'writable' => true,
        ),
  ),

Try this:

Backup /var/lib/nextcloud/

sudo cp -rp /var/lib/nextcloud /var/lib/nextcloud-bak

Change owner:

sudo chown -fR http:nextcloud /var/lib/nextcloud

Change rights:

sudo chmod -fR 770 /var/lib/nextcloud

Check if the message “Writing to the “apps” directory is not possible.” is still there.

That helped!!

(I am glad, you helped me…)

The next issue ist

Access via an untrusted domain

I know, I have to add into config.php the trusted ip-addresses / domains:

  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '192.168.0.0/24',
    2 => '10.8.0.1/24'
  ),

But the error remains the same.

I am not sure about that one.
Are you using a VPN, cause of the 10.8.0.1/24? If so, I have absolutely no experience with that use case.

In my case, nextcloud can be reached over e.g. www.example.com and example.com
So, the section in config.php looks like this:

‘trusted_domains’ =>
array (
0 => ‘127.0.0.1’,
1 => ‘192.168.0.0/24’,
2 => ‘www.example.com’,
3 => ‘example.com’,
),

Maybe someone else can jump in to help you with that issue.

Yes I use a VPN and I want to access the NCloud via the LAN and via the VPN (all members / computer).

The last comma is ok after
´´´example.com’,´´´???

Yes, the last comma is okay.
Looking at your post, I’d say there is a comma missing right after 2 => '10.8.0.1/24'
Actually it should work, at least from 192.168.0.0/24 (no clue about VPN) if you try it like this:

  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '192.168.0.0/24',
    2 => '10.8.0.1/24',
  ),

the sloution for this is

  array (
    0 => 'localhost',
    1 => '192.168.0.*',
    2 => '10.8.0.*',
    3 => '192.168.178.*',
  ),

(wih asteriscs, not netmasks)

I have to execute this repeatedly (crontab). Something seems to change the owner and permission regularly. (Why?)