General Troubleshooting

Introduction

This page gives an overview of general troubleshooting topics and can help to sort out paths addressing your topics.

If you have trouble installing, configuring or maintaining ownCloud, please refer to our community support channel:

The ownCloud forum have a FAQ category where each topic corresponds to typical errors or frequently occurring issues.

Please understand that this channel essentially consist of users like you helping each other. Consider helping others when you can in return for the help you get. This is the only way to keep a community like ownCloud healthy and sustainable!

If you are using ownCloud in a business or otherwise large scale deployment, note that ownCloud GmbH offers the Enterprise Edition with commercial support options.

Bugs

If you think you have found a bug in ownCloud, please:

  • Search for a solution (see the options above)

  • Double-check your configuration

If you can’t find a solution, please use our bugtracker. You can generate a configuration report with the occ config command, with passwords automatically obscured.

General Troubleshooting

Check the ownCloud System Requirements, especially supported browser versions. When you see warnings about code integrity, refer to Code Signing.

Disable Third-Party Apps

Third-party apps may cause problems during upgrades. To avoid this happening, we strongly encourage administrators to always disable third-party apps before upgrades, and for troubleshooting purposes.

Debugging Sync Issues

The data directory on the server is exclusive to ownCloud and must not be modified manually.

Disregarding this can lead to unwanted behaviours like:

  • Problems with sync clients

  • Undetected changes due to caching in the database

If you need to directly upload files from the same server please use a WebDAV command line client like cadaver to upload files to the WebDAV interface at:

https://example.com/owncloud/remote.php/dav

Common Problems / Error Messages

Some common problems / error messages found in your logfiles as described above:

  • SQLSTATE[HY000] [1040] Too many connections → You need to increase the connection limit of your database, please refer to the manual of your database for more information.

  • SQLSTATE[HY000]: General error: 5 database is locked → You’re using SQLite which can’t handle a lot of parallel requests. Please consider converting to another database like described in converting Database Type.

  • SQLSTATE[HY000]: General error: 2006 MySQL server has gone away → Please refer to Troubleshooting for more information.

  • SQLSTATE[HY000] [2002] No such file or directory → There is a problem accessing your SQLite database file in your data directory (data/owncloud.db). Please check the permissions of this folder/file or if it exists at all. If you’re using MySQL please start your database.

  • No basic authentication headers were found → This error is shown in your data/owncloud.log file. Some Apache modules like mod_fastcgi, mod_fcgid or 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. More information on how to correctly configure your environment can be found at the forums.

Troubleshooting the Apache Config

The following content is intended for informational purposes only. No changes should be made.

The configuration of the embedded Apache2 server is located under the directory /etc/apache2/ of the ownCloud container, but not in the standard Debian subdirectories due to the way the image is built. During the build process, the default conf-* and sites-* directories are stripped and replaced with an overlay of their own:

Path (inside the container) Comment

/etc/apache2/apache2.conf

Global config

/etc/apache2/sites-enabled/default.conf

Generated at container startup from the gomplate template /etc/templates/apache.conf.tmpl

/etc/apache2/conf-enabled/

Additional snippets (charset, security, remoteip, servername)

/etc/apache2/ports.conf

Port binding

This means, that the ownCloud Apache2 configuration is stored in the /etc/apache2 directory; it just looks different from a standard Debian installation.

Troubleshooting Logs

In order to start troubleshooting, you will need the relevant log information and the correct log level.

Location of Logfiles

The first step when encountering issues is to check the log files provided by PHP, the embedded Apache server and ownCloud itself. In a Dockerised ownCloud environment, the logs can be found at the following location:

  • The logfile of ownCloud is located at:

    <mount_point>/owncloud.log

  • The Apache2 logs are by default routed to Docker stdout/stderr.

    Error log → /dev/stderr (to override use envvar: OWNCLOUD_ERRORLOG_LOCATION)
    Access log → /dev/stdout (to override use envvar: OWNCLOUD_ACCESSLOG_LOCATION)

    The logging capabilities of Docker should be used to obtain log details.

  • The PHP logs are by default routed to Docker stdout/stderr.
    The logging capabilities of Docker should be used to obtain log details.

    Quick tip reading Docker logs for ownCloud
    docker compose logs owncloud -f

ownCloud Log-Levels

In a standard ownCloud installation the log level is set to Normal.

  • To find any issues you need to raise the log level to All in your additional configuration file, or to Everything on your ownCloud Admin page. Please see Logging Configuration for more information on these log levels.

  • Some logging - for example JavaScript console logging - needs debugging enabled.
    Edit the config and change 'debug' ⇒ false, to 'debug' ⇒ true, Be sure to change it back when you are finished.

  • For JavaScript issues you will also need to view the javascript console. All major browsers have developer tools for viewing the console. Usually you can access them by pressing F12.

Troubleshooting WebDAV

General Troubleshooting

ownCloud uses SabreDAV, and the SabreDAV documentation is comprehensive and helpful.

See:

There is also a well maintained FAQ thread available at the ownCloud Forums which contains various additional information about WebDAV problems.

Error 0x80070043 The network name cannot be found. while adding a network drive

The windows native WebDAV client might fail with the following error message:

Error 0x80070043 "The network name cannot be found." while adding a network drive

A known workaround for this issue is to update your web server configuration.

Apache

You need to add the following rule set to your main web server or virtual host configuration, or the .htaccess file in your document root.

Please keep in mind that the .htaccess file in the ownCloud directory will be overwritten on update. Post upgrading ownCloud, you need to manually restore these changes. See the section Backup Manual Changes in .htaccess for details. 
# Fixes Windows WebDav client error 0x80070043 "The network name cannot be found."
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^(DavClnt)$
RewriteCond %{REQUEST_METHOD} ^(OPTIONS)$
RewriteRule .* - [R=401,L]

Troubleshooting Contacts & Calendar

Service Discovery

Some clients - especially on iOS/Mac OS X - have problems finding the proper sync URL, even when explicitly configured to use it.

If you want to use CalDAV or CardDAV clients together with ownCloud, it is important to have a correct working setup of the following URLs:

https://example.com/.well-known/carddav
https://example.com/.well-known/caldav

Those need to be redirecting your clients to the correct DAV endpoints. If running ownCloud at the document root of your Web server the correct URL is:

https://example.com/remote.php/dav

and if running in a subfolder like owncloud:

https://example.com/owncloud/remote.php/dav

For the first case the .htaccess file shipped with ownCloud should do this work.

If your ownCloud instance is installed in a subfolder called owncloud, edit the .htaccess file and add the following lines:

Redirect 301 /.well-known/carddav /owncloud/remote.php/dav
Redirect 301 /.well-known/caldav /owncloud/remote.php/dav

Now change the URL in the client settings to just use:

https://example.com

instead of e.g.

https://example.com/owncloud/remote.php/dav/principals/username.

There are also several techniques to remedy this, which are described extensively at the Sabre DAV website.

Unable to update Contacts or Events

If you get an error like:

PATCH https://example.com/remote.php/dav HTTP/1.0 501 Not Implemented

it is likely caused by one of the following reasons:

Using Pound reverse-proxy/load balancer

Check if your Pound installation supports the HTTP/1.1 verb. If it does not, update to the latest version.

Misconfigured Web server

Your Web server is misconfigured and blocks the needed DAV methods. Please refer to Troubleshooting WebDAV above for troubleshooting steps.

OAuth2

ownCloud Apps Cannot Connect to the ownCloud Server

If ownCloud clients cannot connect to your ownCloud server, check to see if PROPFIND requests receive HTTP/1.1 401 Unauthorized responses. If this is happening, more than likely your web-proxy server configuration is stripping out the bearer authorization header.

When using an Apache web-proxy server, you may need to add the following SetEnvIf directive to that Apache configuration. Please note that the embedded Apache webserver of the ownCloud image already has this included in the .htaccess file located in the containers /var/www/owncloud directory.

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Missing Data Directory

In situations where the <mount-point> of your compose definition uses NFS or an external RAID system, the mount point may be temporarily unavailable because the resource is not available on the host. If you have experienced this, here’s how ownCloud works and what you can expect.

During normal operation, ownCloud’s data directory contains a hidden file, named .ocdata. The purpose of this file is for setups where the data folder is mounted (such as via NFS) and for some reason the mount disappeared. If the directory isn’t available, the data folder would, in effect, be completely empty and the .ocdata would be missing. When this happens, ownCloud will return a 503 Service not available error, to prevent clients believing that the files are gone.

If the operating environment is restored, the Compose environment needs to be shut down and restarted, after which ownCloud will resume normal operation.

App Synchronization Stalls

One known reason is stray locks. These should expire automatically after an hour. If stray locks don’t expire (identified by e.g. repeated file.txt is locked and/or Exception\\\\FileLocked messages in your data/owncloud.log), make sure that you are running system cron and not Ajax cron (See Background Jobs). See https://github.com/owncloud/core/issues/22116 and https://central.owncloud.org/t/file-is-locked-how-to-unlock/985 for some discussion and additional info of this issue.

Other Issues

Some services like Cloudflare can cause issues by minimizing JavaScript and loading it only when needed. When having issues like a not working login button or creating new users make sure to disable such services first.