Server: Internal server error after upgrading to Nextcloud 19 (from 18)

[rolandixor]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

1. Upgrade.

Expected behaviour

Nothing fancy. Just load as usual.

Actual behaviour

Internal server error.

Server configuration

Operating system:
Ubuntu 18.04.4

Web server:
Apache 2

Database:
(I honestly cannot remember but will update this bug if necessary).

PHP version:
(See above).

Nextcloud version: (see Nextcloud admin page)
19

Updated from an older Nextcloud/ownCloud or fresh install:
18

Where did you install Nextcloud from:
The updater.

Signing status:

Signing status

Login as admin user into your Nextcloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results here.

List of activated apps:

App list

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your Nextcloud installation folder

Nextcloud configuration:

Config report

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your Nextcloud installation folder

or 

Insert your config.php content here. 
Make sure to remove all sensitive content such as passwords. (e.g. database password, passwordsalt, secret, smtp password, …)

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)

LDAP config

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your Nextcloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:

Operating system:

Logs

Web server error log

Web server error log

Insert your webserver log here

Nextcloud log (data/nextcloud.log)

Nextcloud log

Insert your Nextcloud log here

Browser log

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) ...

[kesselb]

Thanks for reporting an issue :+1:

Reports without logs might be closed as unqualified reports!

Closing this report as announced in the issue template. Without logs there is not much we can do. Please visit https://help.nextcloud.com for configuration issues / general advice how to debug a problem.

[rolandixor]

The log is over 40MB and contains both the user's name and IP, is there any relevant information I should look for and post here instead?

[Pingger]

@kesselb according to the GDPR you would then need to provide us with a version of the logfile without sensitive information: so no usernames, no ip addresses, no folder paths!

[kesselb]

@Pingger So? I'm not asking (and never did) to upload logs with sensitive information. Feel free to remove everything that's sensitive. But without a error message there is nothing we can do.

Note: This is the issue tracker of Nextcloud, please do NOT use this to get answers to your questions or get help for fixing your installation. This is a place to report bugs to developers, after your server has been debugged. You can find help debugging your system on our home user forums: https://help.nextcloud.com or, if you use Nextcloud in a large organization, ask our engineers on https://portal.nextcloud.com. See also https://nextcloud.com/support for support options.

_Quoted from the issue template: https://github.com/nextcloud/server/blob/master/.github/ISSUE_TEMPLATE/Bug_report.md_

[rolandixor]

I wasn't simply looking to get answers or help in fixing my installation (I did that myself, thank you). I simply decided it wasn't worth it to continue (or to sift through a 40MB log file with several lines of sensitive information), after reading text like the quoted text above (and more) that basically leaves a bad taste in your mouth.

I wasn't going to say anything, because I don't really feel welcome to.

P.S. - many questions posted on the forums simply get ignored or never get answers. Obviously, people are going to head over to the bug tracker, thinking that at least they may be able to simultaneously get assistance while helping to improve the project by smashing another previously unnoticed bug. But the language that you encounter at various points basically gives the impression that if you're not a big company with money to burn, you better be an expert developer who knows what they're doing, or just simply don't use the product at all. That's not very encouraging, to be honest.

[Pingger]

@Pingger So? I'm not asking (and never did) to upload logs with sensitive information. Feel free to remove everything that's sensitive. But without a error message there is nothing we can do.

@kesselb Yes you did by quoting the template "requires the log", which contains sensitive information according to the GDPR. Update that to "the according error message within the log" and I wouldn't jump on you.

specifically you are one time asking for an "error log" and one time just for the "log", which heavily implies you mean the entire log in that case. I also don't see any reminder, that one should remove any sensitive information contained in that log.

Additionally your issue template asks for far too many irrelevant information! The Client OS and Browser as well as the Browser-Logs are entirely irrelevant for an "Internal Server Error". you ONLY _allowed_ to delete the LDAP section.

And how the F are you supposed to report the signing status if you can't access the nextcloud?!

As rolandixor said, with this issue template and the behaviour of the contributors in other issues and the behaviour in the forums you mentioned: You don't at all feel welcome. It looks more like a "we don't care and we make up arbitrary rules to more easily close important issues without actually acknowleding the bugs behind them, just so we have less issues to deal with. Please just go away"

@rolandixor thank you and I also noticed the bad behaviour of the contributors in the forums and the github issue tracker, which is why I sometimes try to explain to them why they won't get proper information in their issues, but honestly a bit more information would have been nice. e.g. the list of "activated apps" command should return _something_ and the "config report" should also return _something_. The questions for encryption and external storage might also be relevant to the issue.

[rolandixor]

It is true that I could have provided further info, if I knew where to begin (outside of sifting through logs). I did try the forums (both searching extensively and posting), but to no avail. I don't use encryption or external storage, so neither would've been relevant. In the end, I simply downgraded by restoring a backup, and I'm not sure I want to try to upgrade again soon. It's not worth the hassle if I'm going to be stuck in limbo when something goes wrong, and all the information I can find after literally spending nearly an entire day searching and troubleshooting on my own leads nowhere.

[kesselb]

Thanks for your feedback :+1:

I simply decided it wasn't worth it to continue (or to sift through a 40MB log file with several lines of sensitive information), after reading text like the quoted text above

@rolandixor you are referring to "Reports without logs might be closed as unqualified reports!"? I agree with you to use a better wording. I added the comment because many people just ignore this part of the issue template. It was my intention to point out how important logs are.

Obviously, people are going to head over to the bug tracker, thinking that at least they may be able to simultaneously get assistance while helping to improve the project by smashing another previously unnoticed bug.

@rolandixor I'm glad that people are reporting bugs. Triaging issue reports is hard. I don't have access to your machine. We have to work with the information provided by you. The information you provided is: Internal server error after upgrading from Nextcloud 18 to 19. It's not possible to reproduce this error without more context.

But the language that you encounter at various points basically gives the impression that if you're not a big company with money to burn, you better be an expert developer who knows what they're doing, or just simply don't use the product at all.

@rolandixor Mind to link some examples? I'm sure we can improve the used language.

Yes you did by quoting the template "requires the log", which contains sensitive information according to the GDPR. Update that to "the according error message within the log" and I wouldn't jump on you.

@Pingger Fine by me. Mind to suggest a improved version? https://github.com/nextcloud/server/edit/master/.github/ISSUE_TEMPLATE/Bug_report.md

specifically you are one time asking for an "error log" and one time just for the "log", which heavily implies you mean the entire log in that case. I also don't see any reminder, that one should remove any sensitive information contained in that log.

@Pingger Also fine by me. A better issue template helps everyone. My impression is that the majority of users understand what we are asking for. For most issues the actual error message should be enough. It's unusual (and unnecessary in most cases) to upload the complete log. What most people do: Open the log, look for repeating entries, remove sensitive information and post it. It's your responsibility to remove sensitive information if you share logs.

Additionally your issue template asks for far too many irrelevant information! The Client OS and Browser as well as the Browser-Logs are entirely irrelevant for an "Internal Server Error". you ONLY _allowed_ to delete the LDAP section.

@Pingger The issue template is a starting point. It's there to help you (and us). You are free to use a different version. That's actually happening every day. For example:

• https://github.com/nextcloud/server/issues/22152 I find it a bit harder to read (as the other reports) because the format is different (or unexpected to me) but it's fine.
• https://github.com/nextcloud/server/issues/22127 In this case the image makes it much easier to understand the problem. For such a report logs are not required.

I guess there is not the perfect issue template. It always depends on the issue itself. A good report is usually (a clear description what is wrong or a error message) and steps how to reproduce.

And how the F are you supposed to report the signing status if you can't access the nextcloud?!

@Pingger Most people write something like "I'm unable to login and cannot access the signing status".

A It looks more like a "we don't care and we make up arbitrary rules to more easily close important issues without actually acknowleding the bugs behind them"

@Pingger Asking for error messages is not arbitrary. As said above without more context it's hard to judge if a bug is important or not (like this report).

just so we have less issues to deal with

@Pingger Why do you think the number of open issues is important? It does not matter if there are 2400 or 3000 open issues. But I don't see the point to keep issues open we are unable to reproduce because the context is missing.

but honestly a bit more information would have been nice. e.g. the list of "activated apps" command should return _something_ and the "config report" should also return _something_. The questions for encryption and external storage might also be relevant to the issue.

@Pingger fine by me. I'm not sure how to add this and the other points we talked about to the issue template. Often people complain about the issue template because it's to many text already. If we add comments to each point that's even more text. Unfortunately the issue templates on GitHub are not flexible. But some comments like <!-- If the issue happens in Firefox and Chrome skip Client configuration section --> might be a start. I'm looking forward to your suggestions.

many questions posted on the forums simply get ignored or never get answers.

https://help.nextcloud.com/t/how-much-the-support-forum-could-improve/88399 seems a discussion about this topic.

the behaviour of the contributors in other issues and the behaviour in the forums you mentioned: You don't at all feel welcome.

@rolandixor @Pingger Sorry to hear that. Many (including me) contribute to Nextcloud in their spare time. A few people also work for Nextcloud GmbH (a company offering support for Nextcloud). About two weeks ago I had a similar encounter on GitHub. I was not friendly enough and things escalated. As said I contribute to Nextcloud in my spare time and I'm not looking for trouble in my spare time. After this encounter I decided to changed my strategy. Before I often responded to issues, asked for additional information, reminded people to use the issue template or closed issues if they are not reproducible (like in your case). I'm not doing this anymore. If a report does not contain clear steps how to reproduce and/or other information required to reproduce a problem I go ahead. That's much easier and less trouble for me.

@rolandixor if it's important to you I can reopen this issue or you create another one. But with the provided information it's definitely not possible to triage it.

@Pingger I'm not sure why you joined this discussion. If you have a problem feel to create a issue. It's fine to adjust the issue template for your problem and remove all sensitive information from the logs.

[Pingger]

1. I might do that, but no guarantees
2. With the first issue you referenced, I agree, that it is quite hard to read, as it does not properly split the information into sections. The Second referenced issue seems fine to me. I understand that there is no such thing as an issue template, but the one currently in use scares away and leads to people not reading/filling out the necessary information
3. I understand, that those are not helpful at all, but an "Internal Server Error" points to something more severe. I also understand that in this case not much information was given.
4. Aksing for ERROR-Messages is not arbitrary. Asking for Webserver-Logs, Nextcloud-Logs, Browser-Logs no matter the issue at hand seems quite arbitrary.
5. I don't think it is important, but I have seen far too many projects where higher ups did care far too much for it! Requiring a reduction of the count of open issues. This does not solve issues, but instead keeps people from opening actual issues.
6. I will take this into account, when I'm overhauling the issue template.
7. The Solution to this, I found, was doing a short review and reminding the OP of the specifics, that would really help narrowing the issue down (e.g. Please add the Version your are using. Do also have an error in logfile x y? If yes, please add that as well?) and if no proper response was issued within a few days the issue would be closed. Most of the time people will provide the requested information or at least ask how it can be obtained, which is progress in my opinion.
8. I joined this discussion, because I encountered issue #19877 and while using the search function I stumbled upon this issue, looked into it and just saw the reply asking for an implict full log file. I thought I maybe should bring up, that asking for full log files, which contain sensitive information, is a bit over the top and that this should maybe be clarified.

Greetings

[rolandixor]

I once again tried to upgrade, to 18.0.9 - got the same error. I moved the log file to a backup so I could get a clean log, but this is the only message:

{"reqId":"REDACTED","level":0,"time":"2020-10-07T05:25:54+00:00","remoteAddr":"REDACTED","user":"REDACTED","app":"workflowengine","method":"

UPDATE: Also found this in the apache.log:

AH01797: client denied by server configuration: /var/www/cloud/config/getuser

Files are syncing via the desktop client - it is only the web interface that isn't loading.