Внутренняя ошибка сервера owncloud

ownCloud Central

Loading

Источник

Steps to reproduce

  1. Visited URL cloud.********.com
  2. Log on using user credentials
  3. Error Appears

Expected behaviour

Tell us what should happen
Proceed to owncloud user dashboard/front screen after login

Actual behaviour

Tell us what happens instead

Error and below details;

Internal Server Error
The server encountered an internal error and was unable to complete your request.

Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.

More details can be found in the server log.

Technical details
Remote Address: 62.69.33.128
Request ID: WjE9amF0xhTKOTuPMHhDcQAAAEo
Type: OCP\Files\NotFoundException
Code: 0
Message:
File: /var/www/vhosts/.com/cloud..com/lib/private/legacy/helper.php
Line: 570

Trace
#0 /var/www/vhosts/.com/cloud..com/apps/files/lib/Controller/ViewController.php(132): OC_Helper::getStorageInfo(‘/’, false)
#1 /var/www/vhosts/.com/cloud..com/apps/files/lib/Controller/ViewController.php(203): OCA\Files\Controller\ViewController->getStorageInfo()
#2 [internal function]: OCA\Files\Controller\ViewController->index(», », NULL)
#3 /var/www/vhosts/.com/cloud..com/lib/private/AppFramework/Http/Dispatcher.php(159): call_user_func_array(Array, Array)
#4 /var/www/vhosts/.com/cloud..com/lib/private/AppFramework/Http/Dispatcher.php(89): OC\AppFramework\Http\Dispatcher->executeController(Object(OCA\Files\Controller\ViewController), ‘index’)
#5 /var/www/vhosts/.com/cloud..com/lib/private/AppFramework/App.php(98): OC\AppFramework\Http\Dispatcher->dispatch(Object(OCA\Files\Controller\ViewController), ‘index’)
#6 /var/www/vhosts/.com/cloud..com/lib/private/AppFramework/Routing/RouteActionHandler.php(46): OC\AppFramework\App::main(‘ViewController’, ‘index’, Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
#7 [internal function]: OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
#8 /var/www/vhosts/.com/cloud..com/lib/private/Route/Router.php(342): call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
#9 /var/www/vhosts/.com/cloud..com/lib/base.php(929): OC\Route\Router->match(‘/apps/files/’)
#10 /var/www/vhosts/.com/cloud..com/index.php(56): OC::handleRequest()
#11 {main}

It also won’t allow me to create any new folders or upload any documents.

Server configuration

Operating system:

Web server:

Database:

PHP version:

ownCloud version: (see ownCloud admin page)
Version: 10.0.4 (stable)

Updated from an older ownCloud or fresh install:
Fresh Install

Where did you install ownCloud from:

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

Technical information

The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results

  • core
    • EXTRA_FILE
      • .well-known/acme-challenge/cYGuVocgCHWKj7soIUg0RcQTU8qN0uVtVaa5zyRzYeM
      • .well-known/acme-challenge/.htaccess
      • .well-known/acme-challenge/SXSprj5MkDnXcVLfPhLPIYo_Og1D8h6_iK0L74wPRFo
      • .well-known/acme-challenge/2aRy5QAu0toESdka09bidKl3RKd2oyXLbEl7tHWMNOo

Raw output

Array
(
[core] => Array
(
[EXTRA_FILE] => Array
(
[.well-known/acme-challenge/cYGuVocgCHWKj7soIUg0RcQTU8qN0uVtVaa5zyRzYeM] => Array
(
[expected] =>
[current] => 8e49986341f97d183ffb4b1360ba32dca00a575671bd845e08186a22d27f6413eae60805ae476e51406001cd869ef763908a60aacb7a430cf929af0c892723ae
)

                [.well-known/acme-challenge/.htaccess] => Array
                    (
                        [expected] => 
                        [current] => cfa5b683614129d23a3b4619abab08163e70d527e605c9d167627bd87c8fde29fe6ce39c11fa3fe4c6ed97f4d7a883cc3bd90af299ce6e597db891b1a4d60bc3
                    )

                [.well-known/acme-challenge/SXSprj5MkDnXcVLfPhLPIYo_Og1D8h6_iK0L74wPRFo] => Array
                    (
                        [expected] => 
                        [current] => 1be201efeae5705239f686a552b0e3c82184825c718a0b4a69d31bee6de228944aed4b527b07a9951693e5cf35284ac7f963ea8be899d57fbe49a8fa22834639
                    )

                [.well-known/acme-challenge/2aRy5QAu0toESdka09bidKl3RKd2oyXLbEl7tHWMNOo] => Array
                    (
                        [expected] => 
                        [current] => c5493935d2a08c3cdd223d554a40148301af95a5f3cf63812e99a025925c027f135c7b6ddaee433d9d43edb17a0752aa5875e61b1961ca493a6855ee552f9256
                    )

            )

    )

)

The content of config/config.php:

‘********’,
‘passwordsalt’ => ‘********’,
‘secret’ => ‘********’,

/* Trusted Domain URLs */
‘trusted_domains’ =>
array (
0 => ‘cloud.********.com’,
),
‘datadirectory’ => ‘/var/www/vhosts/********.com/cloud.********.com/data’,
‘overwrite.cli.url’ => ‘http://cloud.********.com/’,
‘dbtype’ => ‘mysql’,
‘version’ => ‘10.0.4.4’,
‘dbname’ => ‘********’,
‘dbhost’ => ‘localhost’,
‘dbtableprefix’ => ‘oc_’,
‘dbuser’ => ‘********’,
‘dbpassword’ => ‘********’,
‘logtimezone’ => ‘UTC’,
‘installed’ => true,
‘knowledgebaseenabled’ => true,
‘debug’ => true,
‘mail_from_address’ => ‘noreply’,
‘mail_smtpmode’ => ‘php’,
‘mail_domain’ => ‘cloud.********.com’,

/* Transactional File Locking */
‘filelocking.enabled’ => true,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘redis’ => array(
‘host’ => ‘localhost’,
‘port’ => 6379,
‘timeout’ => 0.0,
‘password’ => », // Optional, if not defined no password will be used.
),
);

«`
Log in to the web-UI with an administrator account and click on
‘admin’ -> ‘Generate Config Report’ -> ‘Download ownCloud config report’
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

**List of activated apps:**

**Are you using external storage, if yes which one:** local/smb/sftp/…
no

**Are you using encryption:** yes/no
no

**Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory/Webdav/…
no
«`

### Client configuration
**Browser:** Opera

**Operating system:** Windows 10

Источник

Steps to reproduce

  1. Logging in from website

Expected behaviour
Normal screen after login should appear (seeing the data etc)

Actual behaviour
Error after login:

Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.
Technical details
    Remote Address: yyy.xxx.yyy.xxx
    Request ID: 01rh8/w8DAWYVV4XKhyg

Server configuration
Operating system: Debian Jessie 8.4
Web server: Apache/2.4.10
Database: mysql Ver 15.1 Distrib 10.0.23-MariaDB
PHP version: PHP 5.6.20-0+deb8u1
ownCloud version (see ownCloud admin page): 9.0.2.2 (from config.php as weblogin doesnt work)
Updated from an older ownCloud or fresh install: from 9.0
ownCloud log (data/owncloud.log): please see below

Special configuration (external storage, external authentication, reverse proxy, server-side-encryption):
No server-side encryption. I triggered an upgrade via apt-get upgrade and then performed sudo -u www-data php ./occ upgrade with terminated without any errors. Then, I disabled the maintanence mode in config.php and rebooted.

There are several errors in /var/www/owncloud/data/owncloud.log like this one (IPs blanked):

{"reqId":"oJZ8JSOK0rRZSJaI5rsV","remoteAddr":"xxx.xxx.xxx.xxx","app":"index","message":"Exception: {\"Exception\":\"Exception\",\"Message\":\"The requested uri(\\\/apps\\\/files\\\/) cannot be processed by the script '\\\/owncloud\\\/index.php')\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/lib\\\/base.php(837): OC\\\\AppFramework\\\\Http\\\\Request->getRawPathInfo()\\n#1 \\\/var\\\/www\\\/owncloud\\\/index.php(39): OC::handleRequest()\\n#2 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/http\\\/request.php\",\"Line\":624}","level":3,"time":"2016-05-03T21:33:46+02:00","method":"GET","url":"\/apps\/files\/","user":"root"}
{"reqId":"U4uToMnS2E+YKYvJMfYz","remoteAddr":"xxx.xxx.xxx.xxx","app":"index","message":"Exception: {\"Exception\":\"Exception\",\"Message\":\"The requested uri(\\\/apps\\\/files\.svg) cannot be processed by the script '\\\/owncloud\\\/index.php')\",\"Car\\\/www\\\/owncloud\\\/lib\\\/base.php(837): OC\\\\AppFramework\\\\Http\\\n#1 \\\/var\\\/www\\\/owncloud\\\/index.php(39): OC::handleRequest()\\n#r\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/http\\\/request.:3,"time":"2016-05-03T21:33:49+02:00","method":"GET","url":"\/apps\/files\"user":"root"}

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

<VirtualHost *:80>
ServerName MYDOMAIN.com
ServerAlias MYDOMAIN-ALIAS.com

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

</VirtualHost>

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

<IfModule mod_ssl.c>
        <VirtualHost *:443>
                ServerAdmin webmaster@localhost
                SSLProxyEngine on         
                ServerName MYDOMAIN.com
                ServerAlias MYDOMAIN-ALIAS.com

                <Directory /var/www/owncloud/>
                        Options +FollowSymlinks
                        AllowOverride All
                        <IfModule mod_dav.c>
                                Dav off
                        </IfModule>
                        SetEnv HOME /var/www/owncloud
                        SetEnv HTTP_HOME /var/www/owncloud
                </Directory>


                <IfModule mod_headers.c>
                        Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
                </IfModule>

                DocumentRoot /var/www/owncloud

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on

                SSLCertificateFile /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/MYDOMAIN/privkey.pem

                SSLHonorCipherOrder on
                SSLCompression          off
                SSLProtocol all -SSLv2 -SSLv3 -TLSv1
                SSLCipherSuite "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK"

        </VirtualHost>

</IfModule>

The owncloud update was triggered by the upgrade of this bunch of packages today:
/var/log/apt/history.log

Start-Date: 2016-05-03  14:21:03
Commandline: apt-get upgrade
Upgrade: apt:amd64 (1.0.9.8.2, 1.0.9.8.3), multiarch-support:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), linux-image-3.16.0-4-amd64:amd64 (3.16.7-ckt20-1+deb8u4, 3.16.7-ckt25-2), librsvg2-2:amd64 (2.40.5-1, 2.40.5-1+deb8u1), libssl1.0.0:amd64 (1.0.1k-3+deb8u4, 1.0.1k-3+deb8u5), apt-transport-https:amd64 (1.0.9.8.2, 1.0.9.8.3), libpam0g:amd64 (1.1.8-3.1+deb8u1, 1.1.8-3.1+deb8u1+b1), libsane-common:amd64 (1.0.24-8, 1.0.24-8+deb8u1), owncloud:amd64 (9.0.0-1.1, 9.0.2-1.1), libgif4:amd64 (4.1.6-11, 4.1.6-11+deb8u1), apt-utils:amd64 (1.0.9.8.2, 1.0.9.8.3), tzdata-java:amd64 (2015g-0+deb8u1, 2016d-0+deb8u1), libc-dev-bin:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), libc-bin:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), libc6:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), ruby:amd64 (2.1.5+deb8u1, 2.1.5+deb8u2), libglib2.0-0:amd64 (2.42.1-1, 2.42.1-1+b1), libglib2.0-dev:amd64 (2.42.1-1, 2.42.1-1+b1), libapt-inst1.5:amd64 (1.0.9.8.2, 1.0.9.8.3), libgtk2.0-bin:amd64 (2.24.25-3, 2.24.25-3+deb8u1), libgtk2.0-common:amd64 (2.24.25-3, 2.24.25-3+deb8u1), owncloud-deps-php5:amd64 (9.0.0-1.1, 9.0.2-1.1), udev:amd64 (215-17+deb8u3, 215-17+deb8u4), base-files:amd64 (8+deb8u3, 8+deb8u4), gir1.2-gtk-2.0:amd64 (2.24.25-3, 2.24.25-3+deb8u1), gnupg:amd64 (1.4.18-7, 1.4.18-7+deb8u1), initramfs-tools:amd64 (0.120, 0.120+deb8u1), libcairo-gobject2:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), libpam-modules:amd64 (1.1.8-3.1+deb8u1, 1.1.8-3.1+deb8u1+b1), libsndfile1:amd64 (1.0.25-9.1, 1.0.25-9.1+deb8u1), libcairo2:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), libudev1:amd64 (215-17+deb8u3, 215-17+deb8u4), libsane:amd64 (1.0.24-8, 1.0.24-8+deb8u1), imagemagick-6.q16:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), nettle-dev:amd64 (2.7.1-5, 2.7.1-5+deb8u1), nodejs:amd64 (5.9.0-1nodesource1~jessie1, 5.11.0-1nodesource1~jessie1), libssl-dev:amd64 (1.0.1k-3+deb8u4, 1.0.1k-3+deb8u5), libapt-pkg4.12:amd64 (1.0.9.8.2, 1.0.9.8.3), libpcre3-dev:amd64 (8.35-3.3+deb8u2, 8.35-3.3+deb8u4), libhogweed2:amd64 (2.7.1-5, 2.7.1-5+deb8u1), librsvg2-common:amd64 (2.40.5-1, 2.40.5-1+deb8u1), systemd-sysv:amd64 (215-17+deb8u3, 215-17+deb8u4), libgtk2.0-0:amd64 (2.24.25-3, 2.24.25-3+deb8u1), libcairo2-dev:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), imagemagick:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), libsane-dev:amd64 (1.0.24-8, 1.0.24-8+deb8u1), systemd:amd64 (215-17+deb8u3, 215-17+deb8u4), gpgv:amd64 (1.4.18-7, 1.4.18-7+deb8u1), libpcrecpp0:amd64 (8.35-3.3+deb8u2, 8.35-3.3+deb8u4), libnettle4:amd64 (2.7.1-5, 2.7.1-5+deb8u1), libpam-modules-bin:amd64 (1.1.8-3.1+deb8u1, 1.1.8-3.1+deb8u1+b1), libmagickwand-6.q16-2:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), tzdata:amd64 (2015g-0+deb8u1, 2016d-0+deb8u1), openssl:amd64 (1.0.1k-3+deb8u4, 1.0.1k-3+deb8u5), libglib2.0-bin:amd64 (2.42.1-1, 2.42.1-1+b1), imagemagick-common:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), libsystemd0:amd64 (215-17+deb8u3, 215-17+deb8u4), linux-libc-dev:amd64 (3.16.7-ckt20-1+deb8u4, 3.16.7-ckt25-2), libpcre3:amd64 (8.35-3.3+deb8u2, 8.35-3.3+deb8u4), libmagickcore-6.q16-2:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), libgtk2.0-dev:amd64 (2.24.25-3, 2.24.25-3+deb8u1), locales:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), libcairo-script-interpreter2:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), libc6-dev:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), owncloud-files:amd64 (9.0.0-1.1, 9.0.2-1.1)
End-Date: 2016-05-03  14:23:46

config.php

<?php
$CONFIG = array (
  'instanceid' => 'abc',
  'passwordsalt' => 'abc',
  'secret' => 'abc',
  'trusted_domains' => 
  array (
    0 => 'MYDOMAIN.com',
  ),
  'datadirectory' => '/var/www/owncloud/data',
  'overwrite.cli.url' => 'https://MYDOMAIN.com/owncloud',
  'dbtype' => 'mysql',
  'version' => '9.0.2.2',
  'dbname' => 'oc-db',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'oc_root',
  'dbpassword' => 'abc',
  'logtimezone' => 'Europe/Berlin',
  'installed' => true,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'preview_libreoffice_path' => '/usr/bin/libreoffice',
  'loglevel' => 2,
  'logfile' => '/var/www/owncloud/data/owncloud.log',
  'appstore.experimental.enabled' => true,
  'maintenance' => false,
  'updatechecker' => false,
  'blacklisted_files' => 
  array (
    0 => '._*',
    1 => '.DS_Store',
    2 => '.DS_STORE',
    3 => '.ds_store',
    4 => '*.log',
    5 => '*.bbl',
    6 => '*.out',
    7 => '*.blg',
    8 => '*.aux',
    9 => '*.toc',
    10 => '*.synctex.gz',
    11 => '*.synctex',
    12 => '*.lof',
    13 => '*.lot',
    14 => '*.bit',
    15 => '*.idx',
    16 => '*.glo',
    17 => '*.ilg',
    18 => '*.out',
  ),
);
Источник

Содержание

  1. Internal Server error 500 #8414
  2. Comments
  3. Steps to reproduce
  4. Expected behaviour
  5. Actual behaviour
  6. Server configuration
  7. 500 Internal server error accessing /owncloud/remote.php/caldav/calendars/brian/defaultcalendar/ #25381
  8. Comments
  9. Steps to reproduce
  10. Expected behaviour
  11. Actual behaviour
  12. Server configuration
  13. Client configuration
  14. Internal Error 500 #21869
  15. Comments
  16. Steps to reproduce
  17. Expected behaviour
  18. Actual behaviour
  19. Server configuration
  20. LDAP configuration (delete this part if not used)
  21. Client configuration
  22. Web server error log
  23. ownCloud log (data/owncloud.log)
  24. Browser log
  25. Footer
  26. Database Error Leads to Internal Server Error (500) #16590
  27. Comments
  28. Actual behaviour
  29. Server configuration
  30. Web server error log
  31. MariaDB
  32. ownCloud log (data/owncloud.log)

Internal Server error 500 #8414

I have a user who has their own owncloud account. Currently this is set to sync on both the server and onto the clients computer. At present the servers owncloud is syncing correctly without any issues but when the clients computer loads owncloud after 10 minutes an error reporting «1060 happened, internal server error 500».

I have looked into other tickets and I can see the some say restart the ownclouds IIS service which has been completed and produced the same error.

The windows client version used is version 1.5.4

Server operating system — Windows

Owncloud version — 6.0.2

The text was updated successfully, but these errors were encountered:

@colinpeak Thanks a lot for reporting issues back to us!

We need some more information to properly support you with your issue!

Can I ask you to follow our guidelines for submitting bugs as described here: https://github.com/owncloud/core/blob/master/CONTRIBUTING.md

Steps to reproduce

  1. Setup owncloud with the same user details on 2 different computers.
  2. set one to download the data and one to download the data from the cloud.
  3. This replicates when we create a new user.

Expected behaviour

The files should sync between both the server and computer.

Actual behaviour

The server uploads but errors on the local computer error 500.

Server configuration

Windows server 2008 r2

Web server:
IIS
Database:

Источник

500 Internal server error accessing /owncloud/remote.php/caldav/calendars/brian/defaultcalendar/ #25381

Steps to reproduce

Expected behaviour

I shouldn’t get 500 errors from caldav backend

Actual behaviour

I get a 500 Internal server error

Server configuration

Operating system:
Linux

Web server:
Apache

Database:
MySQL/MariaDB

PHP version:
5.4.16

ownCloud version: (see ownCloud admin page)
9.0.2

Updated from an older ownCloud or fresh install:
Updated from 8.2.x

Where did you install ownCloud from:
EPEL

Signing status (ownCloud 9.0 and above):
Integrity checker has been disabled. Integrity cannot be verified.

List of activated apps:
Enabled:

  • activity: 2.2.1
  • calendar: 1.2.2
  • comments: 0.2
  • contacts: 1.3.1.0
  • dav: 0.1.6
  • federatedfilesharing: 0.1.0
  • federation: 0.0.4
  • files: 1.4.4
  • files_pdfviewer: 0.8.1
  • files_sharing: 0.9.1
  • files_texteditor: 2.1
  • files_trashbin: 0.8.0
  • files_versions: 1.2.0
  • files_videoplayer: 0.9.8
  • firstrunwizard: 1.1
  • gallery: 14.5.0
  • notifications: 0.2.3
  • provisioning_api: 0.4.1
  • systemtags: 0.2
  • templateeditor: 0.1
  • user_ldap: 0.8.0
    Disabled:
  • encryption
  • external
  • files_external
  • user_external

The content of config/config.php:
<
«system»: <
«log_type»: «owncloud»,
«datadirectory»: «/var/lib/owncloud/data»,
«updatechecker»: false,
«check_for_working_htaccess»: false,
«asset-pipeline.enabled»: false,
«assetdirectory»: «/var/lib/owncloud»,
«apps_paths»: [
<
«path»: «/usr/share/owncloud/apps»,
«url»: «/apps»,
«writable»: false
>,
<
«path»: «/var/lib/owncloud/apps»,
«url»: «/apps-appstore»,
«writable»: true
>
],
«instanceid»: «xxx»,
«passwordsalt»: «_REMOVED SENSITIVE VALUE«,
«secret»: «_REMOVED SENSITIVE VALUE«,
«trusted_domains»: [
«owncloud.example.com»,
«www.example.com»
],
«overwrite.cli.url»: «http://owncloud.example.com/owncloud»,
«dbtype»: «mysql»,
«dbname»: «owncloud»,
«dbhost»: «linux.example.com»,
«dbuser»: «_REMOVED SENSITIVE VALUE«,
«dbpassword»: «_REMOVED SENSITIVE VALUE«,
«version»: «9.0.2.2»,
«installed»: true,
«theme»: «»,
«maintenance»: false,
«forcessl»: false,
«loglevel»: 1,
«log_authfailip»: true,
«mail_from_address»: «owncloud»,
«mail_smtpmode»: «smtp»,
«mail_domain»: «example.com»,
«mail_smtphost»: «smtp.example.com»,
«trashbin_retention_obligation»: «auto»
>
>

Are you using external storage, if yes which one: local/smb/sftp/.
No

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.
No

Client configuration

Browser:
N/A

Operating system:
Linux

Источник

Steps to reproduce

Expected behaviour

Tell us what should happen

Actual behaviour

Tell us what happens instead

Server configuration

Operating system: Ubuntu Server

Web server: Apache

Database: MySQL

PHP version: 5.6

ownCloud version: (see ownCloud admin page)
8.2.2

Updated from an older ownCloud or fresh install:
Updated from 8.1.5

Signing status (ownCloud 9.0 and above):

List of activated apps:

Are you using external storage, if yes which one: local/smb/sftp/.

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.

LDAP configuration (delete this part if not used)

Client configuration

Browser: Chrome

Operating system: OSX

Web server error log

ownCloud log (data/owncloud.log)

This is most recent so there is nothing helpful as to why this error is happening

Browser log

The text was updated successfully, but these errors were encountered:

Mind you nothing has been changed and my owncloud install has been up solid for over a year now but all of a sudden this week I got to access it and I get this 500 error and I notice another user has the same issue as me:
https://forum.owncloud.org/viewtopic.php?f=36&t=32660

My only guess is cron or something that usually runs broke something in the install but the lack of useable logs is not helping me find out what

Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream

please fix this — THX

That shouldn’t be causing a 500 error in a build that still supports it and that said for most folks on a shared platform always_populate_raw_post_data is going to be on.

a first starting point would be to research what was changed within your environment to get to this state (ownCloud itself won’t magically damage itself or its files so there must be changed something, even an update of PHP or something).

As the cron.php is mentioned you should check your cron settings and php-cli environment which is executing that file.

The always_populate_raw_post_data should be also fixed on your side as already suggested. I think the message is not there just for fun.

Ah, as both of you have the «File does not exist: /home/xxx/owncloud.xxx/ownCloud/internal_error.html» message in your logfile you’r probably both are on the same shared hoster?

If yes then it should be obvious that your hoster probably changed something in their environment which is causing those issues.

Have you considered contacting the support of your hoster about that issue?

No we’re not on the same hosted and others have had this too look on forums. Nothing has changed my provider tailed their logs and it’s OC install that’s busted.

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

How are you sure that nothing changed?

I just said in the comment above that my host investigated. We have other OC installs on the same server that are low major version and still chugging along fine.

Please answer the questions above

Im not in any position to explain someone else’s setup. That said I’ve supplied the necessary info for the template of an actual OC dev wants more info I’ll provide it.

I’m just asking you to answer this:

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

If both of your hosters have the same environment like Plesk for example then such issues can be caused by an upgrade of such components. Also webhosters tend to say «we havn’t changed anything» even if they have changed something.

I don’t know what part of I can’t tell you what kind of environment another user that I do not know is on.

Maybe ask him? He isn’t on my host that’s all I know and I know because I trace routed his hostname.

This is not about the environment of the other user. I’m just asking you if that are the logfiles of your server you have posted here or if you have copied from the logfiles of the other user in the forum thread?

If those are your logfiles we can ask the user at the forum if he can ask the support of this hoster because:

  • You have both the same uncommon internal_error.html message in your logfiles
  • Both of your instances stopped to work out of the blue with the Premature end of script headers: error

Why would I post someone else’s log files ? Yes they are mine

Just to be sure. I have seen a lot of things in the last 2 years since i’m giving support at the forums.

Just have asked the other user at the forums to contact his hoster. Maybe they can provide more info/insights.

Cross-Posting from the linked forums post:

I just found out what changed. DreamHost added zend_extension=opcache.so to my phprc file. I removed that line and the site works fine.

Woo Hoo. unintended consequences of a dreamhost modification

So first off I do have one instal as I mentioned above that works fine on dreamhost and I just checked and yep opcode is there.

That said according to OwnCloud doc opcode should be supported so someone might want to file a bug about that.

On the OwnCloud instance that’s 500 erroring is on a different provider Arivxe and opcode is not set in phprc.

This is clearly nothing the bug tracker is for. This seems to be a setup issue. Please try to figure out what the cause of this is.

Once you know which setting/feature/setup is not compatible with owncloud you can report a bug here, but this just seems to be a setup issue and we as owncloud developers can’t do much here.

I will close this because it lacks the essential information of how to reproduce the issue.

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

I checked my phprc on a different host and the same issue caused it and so I would encourage reopening this and editing the title and queuing it to be worked on.

@bkerensa Zend Opcache works fine for most people, myself included. Given that we have seen 2 instances of a broken ownCloud due to this issue, out of likely many hundreds of thousands of installations, I’d say it’s a specific environment issue, and you’re better off getting help from the forums or other support channels.

Looking at logs the breakage happened on first cron run after I upgraded to 8.2.2 so perhaps a regression? I mean its your project if it were mine and I do run open source projects myself I would definitely investigate it more versus write it off to forums or a environment issue.

If you think its environment then ask for more info to rule that out. But again its your call and if it is a regression I guess you will see more of these reports come up.

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

Nearly all instances I’m aware of use Zend opcache and all work fine 🙁 Sadly it seems to be really hard to reproduce.

We are also not aware of any issues on Ubuntu (especially the LTS versions). The packages there just work. Maybe you have some other hints what is different on those systems. If this is not possible, we can’t do much. We always try to investigate, but if this doesn’t show any hints what it could be there is not much we can do.

@bkerensa Where is this «internal_error.html» coming from?

There is a third instance showing issues with opcache but with a different error (400): #21876

Getting more reports about that:

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Database Error Leads to Internal Server Error (500) #16590

Actual behaviour

The server is responding Internal Server Error 500. This error is repeated and exhausts the server resources.

Server configuration

Operating system: CentOS 7

Web server: Apache

Database: MariaDB

PHP version: 5.4.16

ownCloud version: 8.0.3

List of activated apps:
Activity, Deleted files, external storage support, File locking, first run wizard,
mail template editor, pdf viewer, pictures, provisioning Api, share files, text editor,
updates, versions, video viewer.

The content of config/config.php:

‘dbtype’ => ‘mysql’,
‘version’ => ‘8.0.3.4’,
‘dbname’ => ‘owncloud’,
‘dbhost’ => ‘localhost’,
‘dbtableprefix’ => ‘oc_’,
‘installed’ => true,
‘maintenance’ => false,
‘loglevel’ => 0,

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: webdav

Web server error log

X.X.X.X — user [27/May/2015:16:30:46 +0200] «PUT /remote.php/webdav/Products/QualityMonitor/XXX/Pilot/Sample%20Documentation/XXX/79159.xhtml HTTP/1.1» 201 — «-» «Mozilla/5.0 (Macintosh) mirall/1.8.1»

MariaDB

ownCloud log (data/owncloud.log)

The text was updated successfully, but these errors were encountered:

Источник

500 Internal server error accessing /owncloud/remote.php/caldav/calendars/brian/defaultcalendar/ #25381

Comments

brianjmurrell commented Jul 6, 2016

Steps to reproduce

Expected behaviour

I shouldn’t get 500 errors from caldav backend

Actual behaviour

I get a 500 Internal server error

Server configuration

Operating system:
Linux

Web server:
Apache

Database:
MySQL/MariaDB

PHP version:
5.4.16

ownCloud version: (see ownCloud admin page)
9.0.2

Updated from an older ownCloud or fresh install:
Updated from 8.2.x

Where did you install ownCloud from:
EPEL

Signing status (ownCloud 9.0 and above):
Integrity checker has been disabled. Integrity cannot be verified.

List of activated apps:
Enabled:

  • activity: 2.2.1
  • calendar: 1.2.2
  • comments: 0.2
  • contacts: 1.3.1.0
  • dav: 0.1.6
  • federatedfilesharing: 0.1.0
  • federation: 0.0.4
  • files: 1.4.4
  • files_pdfviewer: 0.8.1
  • files_sharing: 0.9.1
  • files_texteditor: 2.1
  • files_trashbin: 0.8.0
  • files_versions: 1.2.0
  • files_videoplayer: 0.9.8
  • firstrunwizard: 1.1
  • gallery: 14.5.0
  • notifications: 0.2.3
  • provisioning_api: 0.4.1
  • systemtags: 0.2
  • templateeditor: 0.1
  • user_ldap: 0.8.0
    Disabled:
  • encryption
  • external
  • files_external
  • user_external

The content of config/config.php:
<
«system»: <
«log_type»: «owncloud»,
«datadirectory»: «/var/lib/owncloud/data»,
«updatechecker»: false,
«check_for_working_htaccess»: false,
«asset-pipeline.enabled»: false,
«assetdirectory»: «/var/lib/owncloud»,
«apps_paths»: [
<
«path»: «/usr/share/owncloud/apps»,
«url»: «/apps»,
«writable»: false
>,
<
«path»: «/var/lib/owncloud/apps»,
«url»: «/apps-appstore»,
«writable»: true
>
],
«instanceid»: «xxx»,
«passwordsalt»: «_REMOVED SENSITIVE VALUE«,
«secret»: «_REMOVED SENSITIVE VALUE«,
«trusted_domains»: [
«owncloud.example.com»,
«www.example.com»
],
«overwrite.cli.url»: «http://owncloud.example.com/owncloud»,
«dbtype»: «mysql»,
«dbname»: «owncloud»,
«dbhost»: «linux.example.com»,
«dbuser»: «_REMOVED SENSITIVE VALUE«,
«dbpassword»: «_REMOVED SENSITIVE VALUE«,
«version»: «9.0.2.2»,
«installed»: true,
«theme»: «»,
«maintenance»: false,
«forcessl»: false,
«loglevel»: 1,
«log_authfailip»: true,
«mail_from_address»: «owncloud»,
«mail_smtpmode»: «smtp»,
«mail_domain»: «example.com»,
«mail_smtphost»: «smtp.example.com»,
«trashbin_retention_obligation»: «auto»
>
>

Are you using external storage, if yes which one: local/smb/sftp/.
No

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.
No

Client configuration

Browser:
N/A

Operating system:
Linux

Источник

Internal Server error 500 #8414

Comments

colinpeak commented Apr 30, 2014

I have a user who has their own owncloud account. Currently this is set to sync on both the server and onto the clients computer. At present the servers owncloud is syncing correctly without any issues but when the clients computer loads owncloud after 10 minutes an error reporting «1060 happened, internal server error 500».

I have looked into other tickets and I can see the some say restart the ownclouds IIS service which has been completed and produced the same error.

The windows client version used is version 1.5.4

Server operating system — Windows

Owncloud version — 6.0.2

The text was updated successfully, but these errors were encountered:

DeepDiver1975 commented Apr 30, 2014

@colinpeak Thanks a lot for reporting issues back to us!

We need some more information to properly support you with your issue!

Can I ask you to follow our guidelines for submitting bugs as described here: https://github.com/owncloud/core/blob/master/CONTRIBUTING.md

colinpeak commented Apr 30, 2014

Steps to reproduce

  1. Setup owncloud with the same user details on 2 different computers.
  2. set one to download the data and one to download the data from the cloud.
  3. This replicates when we create a new user.

Expected behaviour

The files should sync between both the server and computer.

Actual behaviour

The server uploads but errors on the local computer error 500.

Server configuration

Windows server 2008 r2

Web server:
IIS
Database:

Источник

Internal Error 500 #21869

Comments

bkerensa commented Jan 24, 2016

Steps to reproduce

Expected behaviour

Tell us what should happen

Actual behaviour

Tell us what happens instead

Server configuration

Operating system: Ubuntu Server

Web server: Apache

Database: MySQL

PHP version: 5.6

ownCloud version: (see ownCloud admin page)
8.2.2

Updated from an older ownCloud or fresh install:
Updated from 8.1.5

Signing status (ownCloud 9.0 and above):

List of activated apps:

Are you using external storage, if yes which one: local/smb/sftp/.

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.

LDAP configuration (delete this part if not used)

Client configuration

Browser: Chrome

Operating system: OSX

Web server error log

ownCloud log (data/owncloud.log)

This is most recent so there is nothing helpful as to why this error is happening

Browser log

The text was updated successfully, but these errors were encountered:

bkerensa commented Jan 24, 2016

Mind you nothing has been changed and my owncloud install has been up solid for over a year now but all of a sudden this week I got to access it and I get this 500 error and I notice another user has the same issue as me:
https://forum.owncloud.org/viewtopic.php?f=36&t=32660

My only guess is cron or something that usually runs broke something in the install but the lack of useable logs is not helping me find out what

DeepDiver1975 commented Jan 24, 2016

Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream

please fix this — THX

bkerensa commented Jan 24, 2016

That shouldn’t be causing a 500 error in a build that still supports it and that said for most folks on a shared platform always_populate_raw_post_data is going to be on.

ghost commented Jan 24, 2016

a first starting point would be to research what was changed within your environment to get to this state (ownCloud itself won’t magically damage itself or its files so there must be changed something, even an update of PHP or something).

As the cron.php is mentioned you should check your cron settings and php-cli environment which is executing that file.

The always_populate_raw_post_data should be also fixed on your side as already suggested. I think the message is not there just for fun.

ghost commented Jan 24, 2016

Ah, as both of you have the «File does not exist: /home/xxx/owncloud.xxx/ownCloud/internal_error.html» message in your logfile you’r probably both are on the same shared hoster?

If yes then it should be obvious that your hoster probably changed something in their environment which is causing those issues.

Have you considered contacting the support of your hoster about that issue?

bkerensa commented Jan 24, 2016

No we’re not on the same hosted and others have had this too look on forums. Nothing has changed my provider tailed their logs and it’s OC install that’s busted.

ghost commented Jan 24, 2016

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

How are you sure that nothing changed?

bkerensa commented Jan 24, 2016

I just said in the comment above that my host investigated. We have other OC installs on the same server that are low major version and still chugging along fine.

ghost commented Jan 24, 2016

Please answer the questions above

bkerensa commented Jan 24, 2016

Im not in any position to explain someone else’s setup. That said I’ve supplied the necessary info for the template of an actual OC dev wants more info I’ll provide it.

ghost commented Jan 24, 2016

I’m just asking you to answer this:

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

If both of your hosters have the same environment like Plesk for example then such issues can be caused by an upgrade of such components. Also webhosters tend to say «we havn’t changed anything» even if they have changed something.

bkerensa commented Jan 24, 2016

I don’t know what part of I can’t tell you what kind of environment another user that I do not know is on.

Maybe ask him? He isn’t on my host that’s all I know and I know because I trace routed his hostname.

ghost commented Jan 24, 2016

This is not about the environment of the other user. I’m just asking you if that are the logfiles of your server you have posted here or if you have copied from the logfiles of the other user in the forum thread?

If those are your logfiles we can ask the user at the forum if he can ask the support of this hoster because:

  • You have both the same uncommon internal_error.html message in your logfiles
  • Both of your instances stopped to work out of the blue with the Premature end of script headers: error

bkerensa commented Jan 24, 2016

Why would I post someone else’s log files ? Yes they are mine

ghost commented Jan 24, 2016

Just to be sure. I have seen a lot of things in the last 2 years since i’m giving support at the forums.

Just have asked the other user at the forums to contact his hoster. Maybe they can provide more info/insights.

ghost commented Jan 24, 2016

Cross-Posting from the linked forums post:

I just found out what changed. DreamHost added zend_extension=opcache.so to my phprc file. I removed that line and the site works fine.

Woo Hoo. unintended consequences of a dreamhost modification

bkerensa commented Jan 24, 2016

So first off I do have one instal as I mentioned above that works fine on dreamhost and I just checked and yep opcode is there.

That said according to OwnCloud doc opcode should be supported so someone might want to file a bug about that.

On the OwnCloud instance that’s 500 erroring is on a different provider Arivxe and opcode is not set in phprc.

MorrisJobke commented Jan 25, 2016

This is clearly nothing the bug tracker is for. This seems to be a setup issue. Please try to figure out what the cause of this is.

Once you know which setting/feature/setup is not compatible with owncloud you can report a bug here, but this just seems to be a setup issue and we as owncloud developers can’t do much here.

I will close this because it lacks the essential information of how to reproduce the issue.

bkerensa commented Jan 25, 2016

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

I checked my phprc on a different host and the same issue caused it and so I would encourage reopening this and editing the title and queuing it to be worked on.

RobinMcCorkell commented Jan 25, 2016

@bkerensa Zend Opcache works fine for most people, myself included. Given that we have seen 2 instances of a broken ownCloud due to this issue, out of likely many hundreds of thousands of installations, I’d say it’s a specific environment issue, and you’re better off getting help from the forums or other support channels.

bkerensa commented Jan 25, 2016

Looking at logs the breakage happened on first cron run after I upgraded to 8.2.2 so perhaps a regression? I mean its your project if it were mine and I do run open source projects myself I would definitely investigate it more versus write it off to forums or a environment issue.

If you think its environment then ask for more info to rule that out. But again its your call and if it is a regression I guess you will see more of these reports come up.

MorrisJobke commented Jan 25, 2016

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

Nearly all instances I’m aware of use Zend opcache and all work fine 🙁 Sadly it seems to be really hard to reproduce.

We are also not aware of any issues on Ubuntu (especially the LTS versions). The packages there just work. Maybe you have some other hints what is different on those systems. If this is not possible, we can’t do much. We always try to investigate, but if this doesn’t show any hints what it could be there is not much we can do.

@bkerensa Where is this «internal_error.html» coming from?

ghost commented Jan 26, 2016

There is a third instance showing issues with opcache but with a different error (400): #21876

bkerensa commented Jan 26, 2016

ghost commented Jan 30, 2016

Getting more reports about that:

ghost commented Feb 4, 2016

lock bot commented Aug 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Footer

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Источник

Содержание

  1. Internal Server error 500 #8414
  2. Comments
  3. Steps to reproduce
  4. Expected behaviour
  5. Actual behaviour
  6. Server configuration
  7. 500 Internal server error accessing /owncloud/remote.php/caldav/calendars/brian/defaultcalendar/ #25381
  8. Comments
  9. Steps to reproduce
  10. Expected behaviour
  11. Actual behaviour
  12. Server configuration
  13. Client configuration
  14. Internal Error 500 #21869
  15. Comments
  16. Steps to reproduce
  17. Expected behaviour
  18. Actual behaviour
  19. Server configuration
  20. LDAP configuration (delete this part if not used)
  21. Client configuration
  22. Web server error log
  23. ownCloud log (data/owncloud.log)
  24. Browser log
  25. Footer
  26. Database Error Leads to Internal Server Error (500) #16590
  27. Comments
  28. Actual behaviour
  29. Server configuration
  30. Web server error log
  31. MariaDB
  32. ownCloud log (data/owncloud.log)

Internal Server error 500 #8414

I have a user who has their own owncloud account. Currently this is set to sync on both the server and onto the clients computer. At present the servers owncloud is syncing correctly without any issues but when the clients computer loads owncloud after 10 minutes an error reporting «1060 happened, internal server error 500».

I have looked into other tickets and I can see the some say restart the ownclouds IIS service which has been completed and produced the same error.

The windows client version used is version 1.5.4

Server operating system — Windows

Owncloud version — 6.0.2

The text was updated successfully, but these errors were encountered:

@colinpeak Thanks a lot for reporting issues back to us!

We need some more information to properly support you with your issue!

Can I ask you to follow our guidelines for submitting bugs as described here: https://github.com/owncloud/core/blob/master/CONTRIBUTING.md

Steps to reproduce

  1. Setup owncloud with the same user details on 2 different computers.
  2. set one to download the data and one to download the data from the cloud.
  3. This replicates when we create a new user.

Expected behaviour

The files should sync between both the server and computer.

Actual behaviour

The server uploads but errors on the local computer error 500.

Server configuration

Windows server 2008 r2

Web server:
IIS
Database:

Источник

500 Internal server error accessing /owncloud/remote.php/caldav/calendars/brian/defaultcalendar/ #25381

Steps to reproduce

Expected behaviour

I shouldn’t get 500 errors from caldav backend

Actual behaviour

I get a 500 Internal server error

Server configuration

Operating system:
Linux

Web server:
Apache

Database:
MySQL/MariaDB

PHP version:
5.4.16

ownCloud version: (see ownCloud admin page)
9.0.2

Updated from an older ownCloud or fresh install:
Updated from 8.2.x

Where did you install ownCloud from:
EPEL

Signing status (ownCloud 9.0 and above):
Integrity checker has been disabled. Integrity cannot be verified.

List of activated apps:
Enabled:

  • activity: 2.2.1
  • calendar: 1.2.2
  • comments: 0.2
  • contacts: 1.3.1.0
  • dav: 0.1.6
  • federatedfilesharing: 0.1.0
  • federation: 0.0.4
  • files: 1.4.4
  • files_pdfviewer: 0.8.1
  • files_sharing: 0.9.1
  • files_texteditor: 2.1
  • files_trashbin: 0.8.0
  • files_versions: 1.2.0
  • files_videoplayer: 0.9.8
  • firstrunwizard: 1.1
  • gallery: 14.5.0
  • notifications: 0.2.3
  • provisioning_api: 0.4.1
  • systemtags: 0.2
  • templateeditor: 0.1
  • user_ldap: 0.8.0
    Disabled:
  • encryption
  • external
  • files_external
  • user_external

The content of config/config.php:
<
«system»: <
«log_type»: «owncloud»,
«datadirectory»: «/var/lib/owncloud/data»,
«updatechecker»: false,
«check_for_working_htaccess»: false,
«asset-pipeline.enabled»: false,
«assetdirectory»: «/var/lib/owncloud»,
«apps_paths»: [
<
«path»: «/usr/share/owncloud/apps»,
«url»: «/apps»,
«writable»: false
>,
<
«path»: «/var/lib/owncloud/apps»,
«url»: «/apps-appstore»,
«writable»: true
>
],
«instanceid»: «xxx»,
«passwordsalt»: «_REMOVED SENSITIVE VALUE«,
«secret»: «_REMOVED SENSITIVE VALUE«,
«trusted_domains»: [
«owncloud.example.com»,
«www.example.com»
],
«overwrite.cli.url»: «http://owncloud.example.com/owncloud»,
«dbtype»: «mysql»,
«dbname»: «owncloud»,
«dbhost»: «linux.example.com»,
«dbuser»: «_REMOVED SENSITIVE VALUE«,
«dbpassword»: «_REMOVED SENSITIVE VALUE«,
«version»: «9.0.2.2»,
«installed»: true,
«theme»: «»,
«maintenance»: false,
«forcessl»: false,
«loglevel»: 1,
«log_authfailip»: true,
«mail_from_address»: «owncloud»,
«mail_smtpmode»: «smtp»,
«mail_domain»: «example.com»,
«mail_smtphost»: «smtp.example.com»,
«trashbin_retention_obligation»: «auto»
>
>

Are you using external storage, if yes which one: local/smb/sftp/.
No

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.
No

Client configuration

Browser:
N/A

Operating system:
Linux

Источник

Steps to reproduce

Expected behaviour

Tell us what should happen

Actual behaviour

Tell us what happens instead

Server configuration

Operating system: Ubuntu Server

Web server: Apache

Database: MySQL

PHP version: 5.6

ownCloud version: (see ownCloud admin page)
8.2.2

Updated from an older ownCloud or fresh install:
Updated from 8.1.5

Signing status (ownCloud 9.0 and above):

List of activated apps:

Are you using external storage, if yes which one: local/smb/sftp/.

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.

LDAP configuration (delete this part if not used)

Client configuration

Browser: Chrome

Operating system: OSX

Web server error log

ownCloud log (data/owncloud.log)

This is most recent so there is nothing helpful as to why this error is happening

Browser log

The text was updated successfully, but these errors were encountered:

Mind you nothing has been changed and my owncloud install has been up solid for over a year now but all of a sudden this week I got to access it and I get this 500 error and I notice another user has the same issue as me:
https://forum.owncloud.org/viewtopic.php?f=36&t=32660

My only guess is cron or something that usually runs broke something in the install but the lack of useable logs is not helping me find out what

Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream

please fix this — THX

That shouldn’t be causing a 500 error in a build that still supports it and that said for most folks on a shared platform always_populate_raw_post_data is going to be on.

a first starting point would be to research what was changed within your environment to get to this state (ownCloud itself won’t magically damage itself or its files so there must be changed something, even an update of PHP or something).

As the cron.php is mentioned you should check your cron settings and php-cli environment which is executing that file.

The always_populate_raw_post_data should be also fixed on your side as already suggested. I think the message is not there just for fun.

Ah, as both of you have the «File does not exist: /home/xxx/owncloud.xxx/ownCloud/internal_error.html» message in your logfile you’r probably both are on the same shared hoster?

If yes then it should be obvious that your hoster probably changed something in their environment which is causing those issues.

Have you considered contacting the support of your hoster about that issue?

No we’re not on the same hosted and others have had this too look on forums. Nothing has changed my provider tailed their logs and it’s OC install that’s busted.

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

How are you sure that nothing changed?

I just said in the comment above that my host investigated. We have other OC installs on the same server that are low major version and still chugging along fine.

Please answer the questions above

Im not in any position to explain someone else’s setup. That said I’ve supplied the necessary info for the template of an actual OC dev wants more info I’ll provide it.

I’m just asking you to answer this:

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

If both of your hosters have the same environment like Plesk for example then such issues can be caused by an upgrade of such components. Also webhosters tend to say «we havn’t changed anything» even if they have changed something.

I don’t know what part of I can’t tell you what kind of environment another user that I do not know is on.

Maybe ask him? He isn’t on my host that’s all I know and I know because I trace routed his hostname.

This is not about the environment of the other user. I’m just asking you if that are the logfiles of your server you have posted here or if you have copied from the logfiles of the other user in the forum thread?

If those are your logfiles we can ask the user at the forum if he can ask the support of this hoster because:

  • You have both the same uncommon internal_error.html message in your logfiles
  • Both of your instances stopped to work out of the blue with the Premature end of script headers: error

Why would I post someone else’s log files ? Yes they are mine

Just to be sure. I have seen a lot of things in the last 2 years since i’m giving support at the forums.

Just have asked the other user at the forums to contact his hoster. Maybe they can provide more info/insights.

Cross-Posting from the linked forums post:

I just found out what changed. DreamHost added zend_extension=opcache.so to my phprc file. I removed that line and the site works fine.

Woo Hoo. unintended consequences of a dreamhost modification

So first off I do have one instal as I mentioned above that works fine on dreamhost and I just checked and yep opcode is there.

That said according to OwnCloud doc opcode should be supported so someone might want to file a bug about that.

On the OwnCloud instance that’s 500 erroring is on a different provider Arivxe and opcode is not set in phprc.

This is clearly nothing the bug tracker is for. This seems to be a setup issue. Please try to figure out what the cause of this is.

Once you know which setting/feature/setup is not compatible with owncloud you can report a bug here, but this just seems to be a setup issue and we as owncloud developers can’t do much here.

I will close this because it lacks the essential information of how to reproduce the issue.

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

I checked my phprc on a different host and the same issue caused it and so I would encourage reopening this and editing the title and queuing it to be worked on.

@bkerensa Zend Opcache works fine for most people, myself included. Given that we have seen 2 instances of a broken ownCloud due to this issue, out of likely many hundreds of thousands of installations, I’d say it’s a specific environment issue, and you’re better off getting help from the forums or other support channels.

Looking at logs the breakage happened on first cron run after I upgraded to 8.2.2 so perhaps a regression? I mean its your project if it were mine and I do run open source projects myself I would definitely investigate it more versus write it off to forums or a environment issue.

If you think its environment then ask for more info to rule that out. But again its your call and if it is a regression I guess you will see more of these reports come up.

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

Nearly all instances I’m aware of use Zend opcache and all work fine 🙁 Sadly it seems to be really hard to reproduce.

We are also not aware of any issues on Ubuntu (especially the LTS versions). The packages there just work. Maybe you have some other hints what is different on those systems. If this is not possible, we can’t do much. We always try to investigate, but if this doesn’t show any hints what it could be there is not much we can do.

@bkerensa Where is this «internal_error.html» coming from?

There is a third instance showing issues with opcache but with a different error (400): #21876

Getting more reports about that:

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Database Error Leads to Internal Server Error (500) #16590

Actual behaviour

The server is responding Internal Server Error 500. This error is repeated and exhausts the server resources.

Server configuration

Operating system: CentOS 7

Web server: Apache

Database: MariaDB

PHP version: 5.4.16

ownCloud version: 8.0.3

List of activated apps:
Activity, Deleted files, external storage support, File locking, first run wizard,
mail template editor, pdf viewer, pictures, provisioning Api, share files, text editor,
updates, versions, video viewer.

The content of config/config.php:

‘dbtype’ => ‘mysql’,
‘version’ => ‘8.0.3.4’,
‘dbname’ => ‘owncloud’,
‘dbhost’ => ‘localhost’,
‘dbtableprefix’ => ‘oc_’,
‘installed’ => true,
‘maintenance’ => false,
‘loglevel’ => 0,

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: webdav

Web server error log

X.X.X.X — user [27/May/2015:16:30:46 +0200] «PUT /remote.php/webdav/Products/QualityMonitor/XXX/Pilot/Sample%20Documentation/XXX/79159.xhtml HTTP/1.1» 201 — «-» «Mozilla/5.0 (Macintosh) mirall/1.8.1»

MariaDB

ownCloud log (data/owncloud.log)

The text was updated successfully, but these errors were encountered:

Источник

500 Internal server error accessing /owncloud/remote.php/caldav/calendars/brian/defaultcalendar/ #25381

Comments

brianjmurrell commented Jul 6, 2016

Steps to reproduce

Expected behaviour

I shouldn’t get 500 errors from caldav backend

Actual behaviour

I get a 500 Internal server error

Server configuration

Operating system:
Linux

Web server:
Apache

Database:
MySQL/MariaDB

PHP version:
5.4.16

ownCloud version: (see ownCloud admin page)
9.0.2

Updated from an older ownCloud or fresh install:
Updated from 8.2.x

Where did you install ownCloud from:
EPEL

Signing status (ownCloud 9.0 and above):
Integrity checker has been disabled. Integrity cannot be verified.

List of activated apps:
Enabled:

  • activity: 2.2.1
  • calendar: 1.2.2
  • comments: 0.2
  • contacts: 1.3.1.0
  • dav: 0.1.6
  • federatedfilesharing: 0.1.0
  • federation: 0.0.4
  • files: 1.4.4
  • files_pdfviewer: 0.8.1
  • files_sharing: 0.9.1
  • files_texteditor: 2.1
  • files_trashbin: 0.8.0
  • files_versions: 1.2.0
  • files_videoplayer: 0.9.8
  • firstrunwizard: 1.1
  • gallery: 14.5.0
  • notifications: 0.2.3
  • provisioning_api: 0.4.1
  • systemtags: 0.2
  • templateeditor: 0.1
  • user_ldap: 0.8.0
    Disabled:
  • encryption
  • external
  • files_external
  • user_external

The content of config/config.php:
<
«system»: <
«log_type»: «owncloud»,
«datadirectory»: «/var/lib/owncloud/data»,
«updatechecker»: false,
«check_for_working_htaccess»: false,
«asset-pipeline.enabled»: false,
«assetdirectory»: «/var/lib/owncloud»,
«apps_paths»: [
<
«path»: «/usr/share/owncloud/apps»,
«url»: «/apps»,
«writable»: false
>,
<
«path»: «/var/lib/owncloud/apps»,
«url»: «/apps-appstore»,
«writable»: true
>
],
«instanceid»: «xxx»,
«passwordsalt»: «_REMOVED SENSITIVE VALUE«,
«secret»: «_REMOVED SENSITIVE VALUE«,
«trusted_domains»: [
«owncloud.example.com»,
«www.example.com»
],
«overwrite.cli.url»: «http://owncloud.example.com/owncloud»,
«dbtype»: «mysql»,
«dbname»: «owncloud»,
«dbhost»: «linux.example.com»,
«dbuser»: «_REMOVED SENSITIVE VALUE«,
«dbpassword»: «_REMOVED SENSITIVE VALUE«,
«version»: «9.0.2.2»,
«installed»: true,
«theme»: «»,
«maintenance»: false,
«forcessl»: false,
«loglevel»: 1,
«log_authfailip»: true,
«mail_from_address»: «owncloud»,
«mail_smtpmode»: «smtp»,
«mail_domain»: «example.com»,
«mail_smtphost»: «smtp.example.com»,
«trashbin_retention_obligation»: «auto»
>
>

Are you using external storage, if yes which one: local/smb/sftp/.
No

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.
No

Client configuration

Browser:
N/A

Operating system:
Linux

Источник

Internal Server error 500 #8414

Comments

colinpeak commented Apr 30, 2014

I have a user who has their own owncloud account. Currently this is set to sync on both the server and onto the clients computer. At present the servers owncloud is syncing correctly without any issues but when the clients computer loads owncloud after 10 minutes an error reporting «1060 happened, internal server error 500».

I have looked into other tickets and I can see the some say restart the ownclouds IIS service which has been completed and produced the same error.

The windows client version used is version 1.5.4

Server operating system — Windows

Owncloud version — 6.0.2

The text was updated successfully, but these errors were encountered:

DeepDiver1975 commented Apr 30, 2014

@colinpeak Thanks a lot for reporting issues back to us!

We need some more information to properly support you with your issue!

Can I ask you to follow our guidelines for submitting bugs as described here: https://github.com/owncloud/core/blob/master/CONTRIBUTING.md

colinpeak commented Apr 30, 2014

Steps to reproduce

  1. Setup owncloud with the same user details on 2 different computers.
  2. set one to download the data and one to download the data from the cloud.
  3. This replicates when we create a new user.

Expected behaviour

The files should sync between both the server and computer.

Actual behaviour

The server uploads but errors on the local computer error 500.

Server configuration

Windows server 2008 r2

Web server:
IIS
Database:

Источник

Internal Error 500 #21869

Comments

bkerensa commented Jan 24, 2016

Steps to reproduce

Expected behaviour

Tell us what should happen

Actual behaviour

Tell us what happens instead

Server configuration

Operating system: Ubuntu Server

Web server: Apache

Database: MySQL

PHP version: 5.6

ownCloud version: (see ownCloud admin page)
8.2.2

Updated from an older ownCloud or fresh install:
Updated from 8.1.5

Signing status (ownCloud 9.0 and above):

List of activated apps:

Are you using external storage, if yes which one: local/smb/sftp/.

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/.

LDAP configuration (delete this part if not used)

Client configuration

Browser: Chrome

Operating system: OSX

Web server error log

ownCloud log (data/owncloud.log)

This is most recent so there is nothing helpful as to why this error is happening

Browser log

The text was updated successfully, but these errors were encountered:

bkerensa commented Jan 24, 2016

Mind you nothing has been changed and my owncloud install has been up solid for over a year now but all of a sudden this week I got to access it and I get this 500 error and I notice another user has the same issue as me:
https://forum.owncloud.org/viewtopic.php?f=36&t=32660

My only guess is cron or something that usually runs broke something in the install but the lack of useable logs is not helping me find out what

DeepDiver1975 commented Jan 24, 2016

Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream

please fix this — THX

bkerensa commented Jan 24, 2016

That shouldn’t be causing a 500 error in a build that still supports it and that said for most folks on a shared platform always_populate_raw_post_data is going to be on.

ghost commented Jan 24, 2016

a first starting point would be to research what was changed within your environment to get to this state (ownCloud itself won’t magically damage itself or its files so there must be changed something, even an update of PHP or something).

As the cron.php is mentioned you should check your cron settings and php-cli environment which is executing that file.

The always_populate_raw_post_data should be also fixed on your side as already suggested. I think the message is not there just for fun.

ghost commented Jan 24, 2016

Ah, as both of you have the «File does not exist: /home/xxx/owncloud.xxx/ownCloud/internal_error.html» message in your logfile you’r probably both are on the same shared hoster?

If yes then it should be obvious that your hoster probably changed something in their environment which is causing those issues.

Have you considered contacting the support of your hoster about that issue?

bkerensa commented Jan 24, 2016

No we’re not on the same hosted and others have had this too look on forums. Nothing has changed my provider tailed their logs and it’s OC install that’s busted.

ghost commented Jan 24, 2016

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

How are you sure that nothing changed?

bkerensa commented Jan 24, 2016

I just said in the comment above that my host investigated. We have other OC installs on the same server that are low major version and still chugging along fine.

ghost commented Jan 24, 2016

Please answer the questions above

bkerensa commented Jan 24, 2016

Im not in any position to explain someone else’s setup. That said I’ve supplied the necessary info for the template of an actual OC dev wants more info I’ll provide it.

ghost commented Jan 24, 2016

I’m just asking you to answer this:

So you’re saying you both are not on the same hoster but have the same uncommon ‘internal_error.html’ in your logfiles? Or do you just have copied over the logfiles of the other user in here?

If both of your hosters have the same environment like Plesk for example then such issues can be caused by an upgrade of such components. Also webhosters tend to say «we havn’t changed anything» even if they have changed something.

bkerensa commented Jan 24, 2016

I don’t know what part of I can’t tell you what kind of environment another user that I do not know is on.

Maybe ask him? He isn’t on my host that’s all I know and I know because I trace routed his hostname.

ghost commented Jan 24, 2016

This is not about the environment of the other user. I’m just asking you if that are the logfiles of your server you have posted here or if you have copied from the logfiles of the other user in the forum thread?

If those are your logfiles we can ask the user at the forum if he can ask the support of this hoster because:

  • You have both the same uncommon internal_error.html message in your logfiles
  • Both of your instances stopped to work out of the blue with the Premature end of script headers: error

bkerensa commented Jan 24, 2016

Why would I post someone else’s log files ? Yes they are mine

ghost commented Jan 24, 2016

Just to be sure. I have seen a lot of things in the last 2 years since i’m giving support at the forums.

Just have asked the other user at the forums to contact his hoster. Maybe they can provide more info/insights.

ghost commented Jan 24, 2016

Cross-Posting from the linked forums post:

I just found out what changed. DreamHost added zend_extension=opcache.so to my phprc file. I removed that line and the site works fine.

Woo Hoo. unintended consequences of a dreamhost modification

bkerensa commented Jan 24, 2016

So first off I do have one instal as I mentioned above that works fine on dreamhost and I just checked and yep opcode is there.

That said according to OwnCloud doc opcode should be supported so someone might want to file a bug about that.

On the OwnCloud instance that’s 500 erroring is on a different provider Arivxe and opcode is not set in phprc.

MorrisJobke commented Jan 25, 2016

This is clearly nothing the bug tracker is for. This seems to be a setup issue. Please try to figure out what the cause of this is.

Once you know which setting/feature/setup is not compatible with owncloud you can report a bug here, but this just seems to be a setup issue and we as owncloud developers can’t do much here.

I will close this because it lacks the essential information of how to reproduce the issue.

bkerensa commented Jan 25, 2016

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

I checked my phprc on a different host and the same issue caused it and so I would encourage reopening this and editing the title and queuing it to be worked on.

RobinMcCorkell commented Jan 25, 2016

@bkerensa Zend Opcache works fine for most people, myself included. Given that we have seen 2 instances of a broken ownCloud due to this issue, out of likely many hundreds of thousands of installations, I’d say it’s a specific environment issue, and you’re better off getting help from the forums or other support channels.

bkerensa commented Jan 25, 2016

Looking at logs the breakage happened on first cron run after I upgraded to 8.2.2 so perhaps a regression? I mean its your project if it were mine and I do run open source projects myself I would definitely investigate it more versus write it off to forums or a environment issue.

If you think its environment then ask for more info to rule that out. But again its your call and if it is a regression I guess you will see more of these reports come up.

MorrisJobke commented Jan 25, 2016

@MorrisJobke Actually the information is there and basically if a server has Zend opcache enabled it then OC breaks. According to doc this form of caching is supported so this is a bug.

Nearly all instances I’m aware of use Zend opcache and all work fine 🙁 Sadly it seems to be really hard to reproduce.

We are also not aware of any issues on Ubuntu (especially the LTS versions). The packages there just work. Maybe you have some other hints what is different on those systems. If this is not possible, we can’t do much. We always try to investigate, but if this doesn’t show any hints what it could be there is not much we can do.

@bkerensa Where is this «internal_error.html» coming from?

ghost commented Jan 26, 2016

There is a third instance showing issues with opcache but with a different error (400): #21876

bkerensa commented Jan 26, 2016

ghost commented Jan 30, 2016

Getting more reports about that:

ghost commented Feb 4, 2016

lock bot commented Aug 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Footer

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Источник

Понравилась статья? Поделить с друзьями:
  • Внутренняя ошибка сервера nextcloud
  • Внутренняя ошибка сервиса попробуйте обратиться позднее ржд
  • Внутренняя ошибка сервера kyocera 2030
  • Внутренняя ошибка сервера guardant net lira
  • Внутренняя ошибка сервиса код ошибки 500