Owncloud stoped working after update

After applying the Debian update to owncloud-complete-files (10.12.0-1+8.1) my instance is no longer working. I don’t have access to files and all sync actions, including Calendars, are failing.

In the admin screen I see the following error:

Your web server is not yet set up properly to allow file synchronization because the WebDAV interface seems to be broken.

That’s not very helpful as I can’t see why the WebAV is all of a sudden broken?

What happened with this upgrade? And how can I get back in business asap?

Did you update anything else? Maybe something changed in the web server configuration.

If there is something wrong with ownCloud, we’ll need logs to know what’s happening.

1 Like

No other updates.

I’m looking into the logs, but there’s hardly any information to be found. The most relevant information seems to be the message in the admin console: Your web server is not yet set properly…

After increasing the log level, there’s still nothing special in there. It’s basically “Session::validateToken” messages.

The error seems to be in the web server config. But the Apache logs also don’t show any valuable information.

As far as I can see, the biggest change in this respect is the .htaccess file in the ownCloud directory.

Are there any steps I could do to get more valuable information from the logs?

There hasn’t been any change in that file in years. Latest change is 2 years ago for 10.7 and it was related to XSS settings. I doubt that change it causing issues.

From which version did you update?

1 Like

From the previous stable Debian repo version: 10.11.0.

Hi,

Same here! logged an issue on GitHub but it got closed right away…

“Since I’ve updated to 10.12, I get this error: Your web server is not yet set up properly to allow file synchronization because the WebDAV interface seems to be broken. And I don’t have access to my files anymore.
I’m using Apache 2.4.54, PHP 7.4 and MariaDB version 10.5.18 on Debian 11.6”

1 Like

Couple of more questions:

  • Did you modify the .htaccess file yourself? You’ve said the file changed, but we haven’t modified the file.
  • Is ownCloud placed in the web server’s root? Do you usually access to https://my.server/ or https://my.server/path/to/owncloud
1 Like

I never changed the .htaccess file.
I access owncloud via a reverse proxy. OC is placed in /var/www/owncloud. The reverse proxy is taking care of the SSL termination.

Could you try to bypass the reverse proxy and access directly to ownCloud? Hopefully that works.

1 Like

Accessing the server directly does not solve the issue. Same error. No files visible.

I’m not using a reverse proxy and I still have the same issue

Web frontend is performing a PROPFIND request to the backend and expects either 207 or 401 as http status code on the response.

Please open up your developer tools in the browser and look on the network tab for this PROPFIND request - please paste the response in here for further analysis.

1 Like

Thanks for your help!

PROPFIND is returning a 405.

These are the response headers:

HTTP/1.1 405 Method Not Allowed
date: Wed, 15 Mar 2023 14:16:22 GMT
server: Apache/2.4.54 (Debian)
x-xss-protection: 0
x-robots-tag: none
x-download-options: noopen
x-permitted-cross-domain-policies: none
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
content-security-policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *
status: 405 Method Not Allowed
content-length: 0
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=15768000; includeSubDomains; preload;
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

Please let me know if you need additional information.

[Error] Failed to load resource: the server responded with a status of 405 () (admin, line 0)

[Error] Unhandled Promise Rejection: TypeError: result.shift is not a function. (In ‘result.shift()’, ‘result.shift’ is undefined)

reloadCallback (filelist.js:1761)

reloadCallback

(anonymous function) (jquery.min.js:2:28300)

j (jquery.min.js:2:26931)

fireWith (jquery.min.js:2:27740)

(anonymous function) (jquery.min.js:2:28719)

(anonymous function) (client.js:495)

promiseReactionJob

[Error] TypeError: undefined is not an object (evaluating ‘data.ocs.meta’)

(anonymous function) (app.js:331)

j (jquery.min.js:2:26931)

fireWith (jquery.min.js:2:27740)

x (jquery.min.js:4:11265)

(anonymous function) (jquery.min.js:4:14767)

[Error] Refused to execute a script because its hash, its nonce, or ‘unsafe-inline’ does not appear in the script-src directive of the Content Security Policy. (files, line 0, x2)

[Error] TypeError: undefined is not an object (evaluating ‘data.ocs.meta’)

(anonymous function) (app.js:331)

j (jquery.min.js:2:26931)

fireWith (jquery.min.js:2:27740)

x (jquery.min.js:4:11265)

(anonymous function) (jquery.min.js:4:14767)

tweak rewrite conditions in htaccess by C0rby · Pull Request #40584 · owncloud/core · GitHub is the only PR that I’ve found that could be relevant.

You could try to temporary revert those changes and see if there is any improvement. Note that this is mainly to confirm or deny whether that PR is the real cause. I don’t think we want to revert it since it refers to a security issue.

If you want to change the .htaccess file, make sure you have a backup of the file so you can restore the actual version of the file.

3 Likes

The .htaccess was the culprit!

This is the end of my .htaccess after manual revert of #40584

#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /owncloud/core/templates/403.php
ErrorDocument 404 /owncloud/core/templates/404.php
<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteRule ^favicon.ico$ core/img/favicon.ico [L]
  RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
  RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff|ico|jpg|jpeg|json|properties)
  RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$
  RewriteCond %{REQUEST_FILENAME} !/robots.txt
  RewriteCond %{REQUEST_FILENAME} !/remote.php
  RewriteCond %{REQUEST_FILENAME} !/public.php
  RewriteCond %{REQUEST_FILENAME} !/cron.php
  RewriteCond %{REQUEST_FILENAME} !/core/ajax/update.php
  RewriteCond %{REQUEST_FILENAME} !/status.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v1.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v2.php
  RewriteCond %{REQUEST_FILENAME} !/updater/
  RewriteCond %{REQUEST_FILENAME} !/ocs-provider/
  RewriteCond %{REQUEST_FILENAME} !/ocm-provider/
  RewriteCond %{REQUEST_URI} !^/.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /owncloud
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

My config & symptoms:

  • Update of Debian package 10.12.0-1+8.1
  • Very old personal very basic setup migrated from version to version by packages.
  • No file visible in the browser after the upgrade! Nothing happens when clicking on “All Files”
  • The calendar does not appear in the browser except a blank calendar, and Thunderbird sends MODIFICATION_FAILED
  • Same for Contacts
  • No obvious error message in the browser without opening dev tools
  • No error visible in message.log
  • No DB in the database log
  • No error during the upgrade (I’ve restored and remade it…)
  • https ://rock/owncloud/remote.php/dav/addressbooks returns 405 / TypeError: result.shift is not a function
  • New lines appeared in oc_storages for each user (eg local::/var/www/owncloud/data/christ/uploads/ , next to home::christ ) ?!

And now everything works again.

3 Likes

Thank you very much! I copied the settings from your post and that did the trick.

Being without a calendar, if only for half a day, was not really my idea of fun. :wink:

Hope there will be a ‘proper’ solution offered soon.

1 Like

And thanks for the tip!

Let me remark that we DON’T plan to revert tweak rewrite conditions in htaccess by C0rby · Pull Request #40584 · owncloud/core · GitHub because it’s linked to a security issue

I suggest to check your web server and adjust the configuration in order for it to work with the final .htaccess file, otherwise the same problem will happen the next upgrade.

As far as I know, the docker installation works fine with it, so you could have a look there and try to mimic the setup.

1 Like

I don’t think anyone is asking you to revert these changes. However, there seem to be a number of users confronted with the exact same issue after applying the latest update to a fine working installation. The impact for these users was also significant, i.e. a non-functioning ownCloud. And as my installation is perfectly plain, I do expect other users will be faced with the same problem.

I will have a look into the docker image. But it would also be nice to known how a plain install of OC and Apache can all of a sudden cause these issues.