Configuration Notes and Tips
See selinux_configuration for a suggested configuration for SELinux-enabled distributions such as Fedora and CentOS.
Several core PHP settings must be configured correctly, otherwise
ownCloud may not work properly. Known settings causing issues are listed
here. Please note that, there might be other settings which cause
unwanted behavior. In general, however, it is recommended to keep the
php.ini settings at their defaults, except when you know exactly why
the change is required, and its implications.
Keep in mind that, changes to
For PHP version 7.0 onward, replace
php_version with the version
number installed, e.g.,
7.0 in the following examples.
In addition to setting
enable_post_data_reading correctly, ensure that, if
session.save_handler is set to
set to a path on the filesystem which only the web server process (or
process which PHP is running as) can read from and write to.
This is especially important if your ownCloud installation is using a
shared-hosting arrangement. In these situations,
session poisoning can
occur if all of the session files are stored in the same location.
Session poisoning is where one web application can manipulate data in
$_SESSION superglobal array of another.
When this happens, the original application has no way of knowing that this corruption has occurred and may not treat the data with any sense of suspicion. You can read through a thorough discussion of local session poisoning if you’d like to know more.
When suhosin.session.cryptkey is enabled, session data will be transparently encrypted. If enabled, there is less of a concern in storing application session files in the same location, as discussed in session.save_path. Ideally, however, session files for each application should always be stored in a location specific to that application, and never stored collectively with any other.
|This is only relevant if you’re using PHP 5.x.|
Please ensure that you have
post_max_size configured with at least
the minimum amount of memory for use with ownCloud, which is 512 MB.
|Please be careful when you set this value if you use the byte value shortcut as it is very specific. Use K for kilobyte, M for megabyte and G for gigabyte. KB, MB, and GB do not work!|
This determines the size of the realpath cache used by PHP. This value should be increased on systems where PHP opens many files, to reflect the number of file operations performed. For a detailed description see realpath-cache-size. This setting has been available since PHP 5.1.0. Prior to PHP 7.0.16 and 7.1.2, the default was 16 KB.
To see your current value, query your
phpinfo() output for this key.
It is recommended to set the value if it is currently set to the default
of 16 KB. A good reading about the background can be found at
With the assumption of 112 bytes per file path needed, this would allow the cache to hold around 37.000 items with a cache size of 4096K (4M), but only about a hundred entries for a cache size of 16 KB.
|It’s a good rule of thumb to always have a realpath cache that can hold entries for all your files paths in memory. If you use symlink deployment, then set it to double or triple the amount of files.|
The easiest way to get the quantity of PHP files is to use cloc, which
can be installed by running
sudo apt-get install cloc. The cloc
package is available for nearly all distributions.
sudo cloc /var/www/owncloud --exclude-dir=data --follow-links 12179 text files. 11367 unique files. 73126 files ignored. http://cloc.sourceforge.net v 1.60 T=1308.98 s (6.4 files/s, 1283.5 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- PHP 4896 96509 285384 558135 ...
Taking the math from above and assuming a symlinked instance, using
factor 3. For example:
4896 * 3 * 112 = 1.6MB This result shows that
you can run with the PHP setting of 4M two instances of ownCloud.
Having the default of 16 KB means that only 1/100 of the existing PHP file paths can be cached and need continuous cache refresh slowing down performance. If you run more web services using PHP, you have to calculate accordingly.
When you are using
php-fpm, system environment variables like
TMP or others are not automatically populated in the same way as when
php-cli. A PHP call like
getenv('PATH'); can therefore return
an empty result. So you may need to manually configure environment
variables in the appropriate
php-fpm ini/config file.
Here are some example root paths for these ini/config files:
In both examples, the
ini/config file is called
depending on the distribution or customizations which you have made, it
may be in a sub-directory.
Usually, you will find some or all of the environment variables already in the file, but commented out like this:
;env[HOSTNAME] = $HOSTNAME ;env[PATH] = /usr/local/bin:/usr/bin:/bin ;env[TMP] = /tmp ;env[TMPDIR] = /tmp ;env[TEMP] = /tmp
Uncomment the appropriate existing entries. Then run
printenv PATH to
confirm your paths, for example:
$ printenv PATH /home/user/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin: /sbin:/bin:/
If any of your system environment variables are not present in the file then you must add them.
When you are using shared hosting or a control panel to manage your ownCloud virtual machine or server, the configuration files are almost certain to be located somewhere else, for security and flexibility reasons, so check your documentation for the correct locations.
Please keep in mind that it is possible to create different settings for
php-fpm, and for different domains and Web sites. The
best way to check your settings is with label-phpinfo.
If you want to increase the maximum upload size, you will also have to
php-fpm configuration and increase the
post_max_size values. You will need to
php5-fpm and your HTTP server in order for these changes to be
ownCloud comes with its own
owncloud/.htaccess file. Because
can’t read PHP settings in
.htaccess these settings and permissions
must be set in the
This error is shown in your
data/owncloud.log file. Some Apache
mod_proxy_fcgi are not
passing the needed authentication headers to PHP and so the login to
ownCloud via WebDAV, CalDAV and CardDAV clients is failing. Information
on how to correctly configure your environment can be found
the forums but we generally recommend against the use of these modules
and recommend mod_php instead.