Updater 405 [reason phrase] Method Not Allowed



I am trying to update but getting the following error when opening updater:

Client error response [url] https://owncloud.*********.com/index.php/occ/config:list [status code] 405 [reason phrase] Method Not Allowed

This is the only unique error in the logs with "config:list term":

{"reqId":"pOIhJquUBedLOkEeOpnD","level":3,"time":"2017-12-24T11:48:03+00:00","remoteAddr":"","user":"--","app":"PHP","method":"GET","url":"\/index.php\/occ\/config:list","message":"You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead. at \/var\/www\/owncloud\/lib\/composer\/patchwork\/utf8\/src\/Patchwork\/Utf8\/Bootup\/intl.php#18"}

I have installed php-intl and restarted apache but error log is the same. I have also installed all php modules listed in owncloud documentation.

apt-get install php7-intl

intl module is listed in:

php -m

This is a relatively new install, I followed the install guide so something is not right with owncloud or documentation. What am I missing here?

Operating system: Ubuntu 16.04
Web server: Apache/2.4.18
Database: Mysql 5.7
PHP version: PHP 7.0.22-0ubuntu0.16.04.1
ownCloud version: (see ownCloud admin page)

The content of config/config.php:
I don't see admin page anywhere even though I have added my user to admin groups, was the UI changed?

root@nuclear:~# sudo -u www-data php occ config:list system
Could not open input file: occ

Documentation should reflect that absolute path is required (at least for me):

sudo -u www-data php /var/www/owncloud/occ config:list system

    "system": {
        "instanceid": "oc3pd4evmqud",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
        "datadirectory": "\/var\/www\/owncloud\/data",
        "overwrite.cli.url": "http:\/\/owncloud.*************.com",
        "dbtype": "mysql",
        "version": "",
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "UTC",
        "installed": true,
        "updater.secret": "***REMOVED SENSITIVE VALUE***"

I have also followed https://doc.owncloud.org/server/10.0/admin_manual/installation/source_installation.html

I added te following to /etc/apache2/sites-available/owncloud.conf with no change:

Alias /owncloud "/var/www/owncloud/"

    <Directory /var/www/owncloud/>
      Options +FollowSymlinks
      AllowOverride All

     <IfModule mod_dav.c>
      Dav off

     SetEnv HOME /var/www/owncloud
     SetEnv HTTP_HOME /var/www/owncloud


I also ran the following commands:

a2enmod rewrite
a2enmod headers
a2enmod env
a2enmod dir
a2enmod mime

a2enmod ssl
a2ensite default-ssl
service apache2 reload

Looking at console in chrome with updater error window open I see the following error:

Failed to load resource: the server responded with a status of 403 (Forbidden) 

This seemed to me like htaccess related but I already tried following owncloud setup apache documentation as outlined above with no change. The file gets recreated after deletion when updater is opened.


From what i know the updater app is not really reliable. Personally i'm just doing the manual updates on my installation and never face such issues.

Additionally if the "intl" message keeps filling your logfiles then i think you havn't installed that module correctly / completely. Maybe there are more issues in your environment like that which is blocking the updater app to work correctly?


Manual install is impractical to the point where it makes using owncloud not worth the trouble.

I believe intl error only appeared in the logs once per every updater open action. Further more "intl" apears in php-m module list so I don't see how it could not be installed correctly. I assume there are other issues one way or another, but what are they? :slight_smile: I tried everything in the documentation and the only issue I have is with the updater.

I also updated the question with info from the console with an interesting error.


I think it could be possible that you have two different PHP installation or something similar. From what i know php -m is only showing modules which are enabled on the command line as well, the webserver is using another set of installed/enabled modules.

Overall i would solve the intl issue first and then to more digging into the "method not allowed" on the internet.


Here is a list of installed packages, it seems only one version of php is isntalled to me:

root@nuclear:~# apt list --installed | grep php

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libapache2-mod-php/xenial,now 1:7.0+35ubuntu6 all [installed]
libapache2-mod-php7.0/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php/xenial,now 1:7.0+35ubuntu6 all [installed]
php-common/xenial,now 1:35ubuntu6 all [installed,automatic]
php-curl/xenial,now 1:7.0+35ubuntu6 all [installed]
php-gd/xenial,now 1:7.0+35ubuntu6 all [installed,automatic]
php-gettext/xenial,now 1.0.11-2build1 all [installed]
php-imagick/xenial,now 3.4.0~rc6-1ubuntu3 amd64 [installed]
php-intl/xenial,now 1:7.0+35ubuntu6 all [installed]
php-mbstring/xenial,now 1:7.0+35ubuntu6 all [installed]
php-mcrypt/xenial,now 1:7.0+35ubuntu6 all [installed]
php-mysql/xenial,now 1:7.0+35ubuntu6 all [installed]
php-pear/xenial,now 1:1.10.1+submodules+notgz-6 all [installed,automatic]
php-phpseclib/xenial,now 2.0.1-1build1 all [installed,automatic]
php-tcpdf/xenial,now 6.0.093+dfsg-1ubuntu1 all [installed,automatic]
php-xml/xenial,now 1:7.0+35ubuntu6 all [installed,automatic]
php-zip/xenial,now 1:7.0+35ubuntu6 all [installed]
php7.0/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 all [installed,automatic]
php7.0-cli/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed,automatic]
php7.0-common/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed,automatic]
php7.0-curl/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-gd/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-intl/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-json/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-mbstring/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-mcrypt/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-mysql/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-opcache/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed,automatic]
php7.0-readline/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed,automatic]
php7.0-xml/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
php7.0-zip/xenial-updates,xenial-security,now 7.0.22-0ubuntu0.16.04.1 amd64 [installed]
phpmyadmin/xenial-updates,now 4: all [installed]

phpinfo() output has intl section too so it is available.

    Internationalization support	enabled
    version	1.1.0
    ICU version	55.1
    ICU Data version	55.1
    Directive	Local Value	Master Value
    intl.default_locale	no value	no value
    intl.error_level	0	0
    intl.use_exceptions	0	0


The "intl" message proofs something else so now there is the question who is right? The message seems to be coming from a 3rdparty library and i don't think that this library is wrong here.

Personally i don't think that it worth to dig any deeper into this. While we have discussed this here you would have done 10 manual updates of ownCloud. :slight_smile:


If it can't be updated via web gui it is unusable. I don't want to have to use command line and risk data loss every single time there is a minor update...


Actually now I no longer see any errors from opening the Updater. The only thing in the log since I emptied it is an error about missing mail template which I assume can be ignored safely.

the htaccesstest file has this:

HTACCESSFAIL: This is used for testing whether htaccess is properly enabled to disallow access from the outside. This file can be safely removed.

I cant find much info on what his file tests for exactly and how it works.


I think you're more into risking updating issues and data loss with the updater app then with the manual way. Everything i have read so far is suggesting to go the manual route and there is probably a reason for this. :slight_smile:


Ok, just tried and it failed before I even got started.

cd /var/www/owncloud/
sudo -u www-data ./occ maintenance:mode --on

sudo: ./occ: command not found

yes occ file exists.

This is from official owncloud documentation. https://doc.owncloud.org/server/10.0/admin_manual/maintenance/upgrade.html

that is the problem with manual update, nothing ever works as documented not tomention how easy it is to accidentaly dete data folders in command line. And then on top of that you have to disable apache meaning the whole server is down during the whole update process every single time!!


Mhhh, a little bit above another command seems to be shown:

sudo -u www-data php occ maintenance:mode --off

Maybe this works for you? Disabling Apache is nothing i'm doing during updates and this works fine for me.

In general if there are any issues with the documentation then maybe there is a place to report to report these? You could head over to the github issue trackers of ownCloud, could be possible that you can report something like that there.

I think you just need to consider that there are so many different linux based operating systems out there so not everything containing command line instructions are always working. This is probably nothing what can be achieved in a documentation of a software like ownCloud.


That kind of shows that manual install is not reliable, if even official documentation is either incorrect or unnecessary.

I got it installed evenually but it's not at all that simple. Documentation doesn't even mention that you will need to chown the new dir even though it will be required 100% of the time. Absolutely terrible documentation...

Even with that known and remembered every time you still have to go through securing permissions on owncloud dir EVERY time you update! This is certainly going to cause a huge number of insecured installations... I mean I am not gonna do that now after spending 3 hours on owncloud already, and will likely forget to do it later...


I think you're more then welcome to contribute your experience to the documentation. No one is perfect and i think no one can expect that a documentation is complete or fully reliable, linux is just a running target and is so different as already mentioned above.


First of all the docs I used are not Wiki pages. Second I don't expect perfection but I would at least expect it to be complete, there is no excuse not to include a chmod command when the upgrade will fail 100% of the time if it's not executed.

The only reason I am not using nextcloud is that cli client is missing one feature. I would recommend everyone to switch unless there is a specific reason not to.


And how do you know that it is known that the chmod is required? Maybe it didn't failed for the documentation writer and thus he/she didn't included it? Maybe the documentation is complete for the writer and he/she just don't know what you're currently describing?

I think a documentation can be only complete if people following it are giving feedback and reporting issues with it or even contributing to it for completeness.

I just did a few seconds search and found out that there is https://github.com/owncloud/documentation which has information how to create an issue and how to contribute to the documentation.


I know because if you download a fresh .tar file and extract it, you will obviously not have correct ownership, especially since apache username is different on different distros. The only way the writer could have reasonably missed this is if they didn't even test the instruction they wrote. Again it's not a wiki so there is no simple way to contribute to it. Github issue sumbission is not even mentioned in the docs. Even if it was The last issue I opened had no response 3 even weeks later. The chown issue is not acceptable even for a wiki, let alone for non-user editable documentation that is used for both free users and enterprise users.


If i check https://doc.owncloud.org/server/latest/admin_manual/installation/source_installation.html#run-the-installation-wizard i see the following instructions mentioned chmod:

chown -R www-data:www-data /var/www/owncloud/

Seems you just have missed that part of the installation guide or are you referring to any other ownership / permissions?

But i can just again point you to contribute to the documentation issue tracker i have linked above if there are more things unclear.

I see no reason why we both should continue here as it seems we're running in circles and nothing would change as we speak. :slight_smile: You probably need to take the route to create an issue, create a pull request with some recommended changes to the documentation or live with the current state of the documentation without complaining about that state. :slight_smile:


I did not use the guide you linked, why would I when I wasn't installing but upgrading? I never said something was unclear, it is plain wrong or incomplete and untested/unverified. Like I already said github issues are being ignored, why would I waste time when at least 2 issues I have opened in the past have been ignored... Even if that's not the case, if admins can post untested and non-working guides there is something seriously wrong with the people in charge. You can't blame community for posting false information on a private domain. As far as I am concerned owncloud is a dead project, I will be moving to nextcloud at the earliest opportunity.


Because you have talked about wrong chmod commands during the installation:

Why do you think issues gets ignored? Maybe there are more important things to do or issues with higher priority? Neither you nor i have probably the knowledge about this so personally i wouldn't claim something like this out of frustration if you don't get the attention you're expecting.

Maybe it was tested and just didn't happen for the writer as pointed out above? Again i personally wouldn't claim something like this without having the knowledge/backgrounds on how the documentation is written.

Could you please point me to the post where i have blamed someone for something? I think there is currently a HUGE misunderstanding here.

Maybe you don't understand my intention to explain why there might be issues in the documentation and that it is only possible to improve a documentation if some one is reporting issues with it or contributing to the documentation.


Yes I talked about chown and chmod commands being wrong but when did I say that it was in the installation guide??

The reasons why issues get ignored do not matter, the fact is they are. Result is the same no matter the reason - issues not getting fixed. There is no point in wasting my time submitting issues when they aren't being looked at.

You are repeating the same thing again, I already explained that chown command is mandatory and the upgrade will not work without it no matter what.

I didn't mean to imply you did blame anyone, I simply stated that this particular problem is with the admins who posted the false and untested article which is disturbing.

I understand what you are saying but again again this was not a wiki, standards should be much higher, and false information is unacceptable even in a user-editable wiki.