Can't write into config directory!

Hi All,

I’m currently deploying a new installation for Nextcloud 11.
I’m using the following setup:

CentOS 7.3.1611
Apache 2.4.6/php 7.0.14/MariaDB 5.5.52
clean install of Nextcloud 11

I’ve created a standaard virtual host over port 80. ( no ssl yet )

<VirtualHost *:80>

  ServerName file.domain.com
  DocumentRoot /var/www/html/file.domain.com
  ErrorLog /var/log/httpd/file.domain.com/error.log
  CustomLog /var/log/httpd/file.domain.com/access.log combined
        <Directory "/var/www/html/file.domain.com">
                Options +FollowSymLinks
                Options -Indexes
                AllowOverride All

                SetEnv HOME /var/www/html/file.domain.com
                SetEnv HTTP_HOME /var/www/html/file.domain.com

                <IfModule mod_dav.c>
                        Dav off
                </IfModule>
                Require all denied
        </Directory>
        <Directory "/var/www/html/file.domain.com/data">
                # just in case if .htaccess gets disabled
                Require all denied
        </Directory>
</VirtualHost>

Apache finds the syntax’s used OK and httpd starts without issues.

# httpd -S
VirtualHost configuration:
*:80                   file.domain.com (/etc/httpd/conf.d/file.domain.com.conf:1)
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex default: dir="/run/httpd/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex authdigest-client: using_defaults
PidFile: "/run/httpd/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache" id=48
Group: name="apache" id=48
Can't write into config directory!
This can usually be fixed by giving the webserver write access to the config directory.

I also ran the Strong Permissions Script from the Admin manual to set permissions correct.

But when I go to file.domain.com (substituted domain.com for privacy) I get this message:

Can’t write into config directory!
This can usually be fixed by giving the webserver write access to the config directory.

Oddly enough, apache IS the owner of the config directory and underlaying files:

    # ll /var/www/html/file.domain.com/ 
    drwxr-x---.  2 apache apache    66 Jan  5 17:09 config

    # ll /var/www/html/file.domain.com/config/
    -rw-r-----. 1 apache apache   587 Jan  5 17:10 config.php

Even when I do a recursive chmod 777 on the config directory the message in de browser still displays the same message.

Did anyone has had similar problems.

Hi

— sorry for my english :slight_smile: ----

Did you copied the config.php? Maybe renaming the config.php and try again?
That reactivate the install steps -> I have the same premissions on Ubuntu

or try: Require all granted or comment out -> restart your apache2.

I added your config:

And became an error 403 - forbidden (with: Require all denied)

Maybe that can help

Did you set the SELinux attributes for the data, apps and config directories to httpd_sys_rw_content_t?

Have a look at the section on SELinux configuration in the admin manual.

I did some digging after the remark of pjsr. Thanks for this:

After googling some selinux issues I came to this site: https://blog.lysender.com/2015/07/centos-7-selinux-php-apache-cannot-writeaccess-file-no-matter-what/ and followed some of the instructions.

ls -Z /var/www/html/file.domain.com I found this for config, data, and apps.

drwxr-x---. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 apps
drwxr-x---. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 data
drwxr-x---. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 config

Unfortunately I did not find anything usefull commands from the SE linux link provided by pjsr.
I issued the commands from the blog mentioned:

# sudo chcon -t httpd_sys_rw_content_t /var/www/html/file.domain.com/data
# sudo chcon -t httpd_sys_rw_content_t /var/www/html/file.domain.com/config
# sudo chcon -t httpd_sys_rw_content_t /var/www/html/file.domain.com/apps

Although I do not see any changes in ls -Z output, my nextcloud installation starts without any Can’t write error messages.
Now I only need to find out why this keeps appearing under Security & setup warnings

Error occurred while checking server setup

Our connection from the host to the big bad internet goes through a http proxy.

I neatly filled in the proxy address and port in the config.php file of nextcloud.
'proxy' => '192.10.10.10:3128',

But I get a lot of cURL messages not able to connect to the internet.
Checking for new daily builds goes without issues. As well as listing all the Not Enabled Apps. Which would suggest the proxy does his job.

Error	internet_connection_check	GuzzleHttp\Exception\ConnectException: cURL error 7: Failed to connect to 192.10.10.10: Permission denied
/var/www/html/file.domain.com/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 103: GuzzleHttp\Exception\RequestException wrapException(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Ring\Exception\ConnectException))
/var/www/html/file.domain.com/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 132: GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
/var/www/html/file.domain.com/3rdparty/react/promise/src/FulfilledPromise.php - line 25: GuzzleHttp\RequestFsm->GuzzleHttp\{closure}(Array)
/var/www/html/file.domain.com/3rdparty/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php - line 55: React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)
/var/www/html/file.domain.com/3rdparty/guzzlehttp/guzzle/src/Message/FutureResponse.php - line 43: GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)
/var/www/html/file.domain.com/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 134: GuzzleHttp\Message\FutureResponse proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))
/var/www/html/file.domain.com/3rdparty/guzzlehttp/guzzle/src/Client.php - line 165: GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
/var/www/html/file.domain.com/3rdparty/guzzlehttp/guzzle/src/Client.php - line 125: GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request))
/var/www/html/file.domain.com/lib/private/Http/Client/Client.php - line 137: GuzzleHttp\Client->get('http //www.gith...', Array)
/var/www/html/file.domain.com/settings/Controller/CheckSetupController.php - line 124: OC\Http\Client\Client->get('http //www.gith...')
/var/www/html/file.domain.com/settings/Controller/CheckSetupController.php - line 107: OC\Settings\Controller\CheckSetupController->isSiteReachable('www.github.com')
/var/www/html/file.domain.com/settings/Controller/CheckSetupController.php - line 363: OC\Settings\Controller\CheckSetupController->isInternetConnectionWorking()
[internal function] OC\Settings\Controller\CheckSetupController->check()
/var/www/html/file.domain.com/lib/private/AppFramework/Http/Dispatcher.php - line 160: call_user_func_array(Array, Array)
/var/www/html/file.domain.com/lib/private/AppFramework/Http/Dispatcher.php - line 90: OC\AppFramework\Http\Dispatcher->executeController(Object(OC\Settings\Controller\CheckSetupController), 'check')
/var/www/html/file.domain.com/lib/private/AppFramework/App.php - line 114: OC\AppFramework\Http\Dispatcher->dispatch(Object(OC\Settings\Controller\CheckSetupController), 'check')
/var/www/html/file.domain.com/lib/private/AppFramework/Routing/RouteActionHandler.php - line 47: OC\AppFramework\App main('OC\\Settings\\Con...', 'check', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
[internal function] OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
/var/www/html/file.domain.com/lib/private/Route/Router.php - line 299: call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
/var/www/html/file.domain.com/lib/base.php - line 1010: OC\Route\Router->match('/settings/ajax/...')
/var/www/html/file.domain.com/index.php - line 40: OC handleRequest()
{main}

Did you do the following from the SELinux section?

sudo setsebool -P httpd_can_network_connect on

Not sure if this is needed for proxy; I don’t have any experience working with proxies.
The easiest way to check if you are hit by a SELinux problem is, is to temporarily disable it:

`sudo setenforce 0`

Then test your set-up. If it works after “setenforce 0”, you know that you have to further dig into SELinux related problems.

Don’t forget to reenable SELinux again:

`sudo setenforce 1`

Setting httpd_can_network_connect to on seems to resolve the permission denied problem.

Thanks for all the help!