Upgrading to 10.3.1


I finally upgraded from 10.1 to 10.3.

I ran in an issue where the command line commands for occ would claim it was was for command line only like it could not detect that php-cli was active.

I had to comment out lines 69 to 72 in console.php. 
    	if (!OC::$CLI) {
		echo "This script can be run from the command line only" . PHP_EOL;

With that commented out the commands would run without error.

Also, after the upgrade. It all seems to work well. I do see a few files have not passed the integrity check.

- core
		- .htaccess
- systemtags
		- l10n/af_ZA.js
		- l10n/mr.json
		- l10n/af_ZA.json
		- l10n/mr.js
- comments
	- l10n/uz.js
	- l10n/uz.json

I can see the .htaccess has a for PHP:
“AddHandler application/x-httpd-ea-php72 .php .php7 .phtml”

However, the other items in the I10n folder, came with the upgrade. Can I just clear them?

– Edit check override found.

I found if I added


Directly after the last original line in the .htaccess file and placed any additional entries after this it passes the check.

I also cleared the extra files without error.

Still wondering about the PHP-cli issue.

  • Mike


this seems to me like a not fully correctly done upgrade by following the instructions the ownCloud team is giving at:


AFAIK the “EXTRA_FILES” are too much files which should have been deleted before copying over the new files from the update.


for this i have grepped through my own ownCloud installation and found the following:

It seems ownCloud is evaluating the return value of the php_sapi_name() function to determine if the occ command line tool is running in CLI mode and on your environment this function doesn’t return either cli or phpdbg as expected by ownCloud.

It looks to me that this is a problem in your specific environment, maybe you can test this on your own to see what your php command line binary is returning via:

printf '<?php echo php_sapi_name() . "\r\n";?>' | php

In my environment this is returning cli as expected.

Those were the instructions I followed. I must have messed up somewhere.

I’ll try the CLI code provided.

  • Mike

I ran the command on the command line.

root [/]# printf '' | php

It returns ‘cli’.


it seems the occ tool has the following on top:

#!/usr/bin/env php

which could be something different then just calling php. Maybe calling the previous script like:

printf '<?php echo php_sapi_name() . "\r\n";?>' | /usr/bin/env php

is giving a different output?


I still received ‘cli’ with running:

printf ‘<?php echo php_sapi_name() . "\r\n";?>’ | /usr/bin/env php

root [/]# printf '' | /usr/bin/env php

Interesting development. If I run the following command as root:

sudo -u www-data php occ

I get the following:

[root@host90 public_html]# sudo -u www-data php occ

Set-Cookie: oc879v6bri0n=b90696cc22652bc0b0449103f0ab27a9; path=/; HttpOnly

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Set-Cookie: oc_sessionPassphrase=QWUYm4OW%2FojEtxwV9iYLjbwAE%2BHQvrwVmwqekFNHtdSKu%2BG5OuXPoG18NXp5KbyJzlST4bDwOSj7l%2B%2FMaapU9IOyRnhWAnkR52yqXjS%2F9E9sZZrlnXCI1r28IR6%2BQ1PC; path=/; HttpOnly

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 *

X-XSS-Protection: 1; mode=block

X-Content-Type-Options: nosniff

X-Frame-Options: SAMEORIGIN

X-Robots-Tag: none

X-Download-Options: noopen

X-Permitted-Cross-Domain-Policies: none

Content-type: text/html; charset=UTF-8

This script can be run from the command line only

If I switch user first ‘[root@host90 public_html]# su www-data’ the run ‘php occ’ it works correctly.

Perhaps there is an issue on my system that ‘sudo -u’ is not actually switching to the assigned user?

  • Mike


i’m not that familiar with different linux environments but it looks to me indeed that a different php environment/binary is used depending on the user (root = correct PHP cli binary, www-data = web server binary, not the expected cli binary) in relation of the use via sudo.

At this point, we have now worked through what process I need to take in order to have the upgrade operations to function correctly. My system seems to be a little different than a stock Centos 7 install.

I’m running this on a cPanel server with current cPanel running on Centos 7.

Thanks for your help.

  • Mike
1 Like