[RFC] Standard way for obtaining debug information


Across the different public repositories hosting Nextcloud related software, users are requested acquire various pieces of information about their installation when creating issues.

On one hand, it makes sense for maintainers to be able to have critical information as early as possible.
On the other hand, collecting all that information by hand is time consuming and annoying - especially so if you already suspect that the info isn’t going to be useful.

For people finding bugs in Nextcloud instances hosted by others (their employer, for example), obtaining simple information like the installation method or version of PHP can already very painful.
The person responsible for needs to provide their time as well. Not everyone is going to grant you SSH access. Is cron called from inside Docker? Is it a systemd timer on the host?
Another day, another admin’s shift, go back to start - I’m passionate about Nextcloud, they might not be…

Some of the information might be redundant - like for instance asking about the type of database that is already included with occ config:list system - the main repo does that.

Then there’s the issue with pasting nextcloud.log on a public issue tracker… and some projects outright closing any issues that don’t provide it.
“control over my data”? There needs to be a better way.

The “system report” under “Support” comes close but I can’t easily send a link to that to my admin (other functions on the same page) and the return path of the result is impractical to use. When talking about posting public issues, the password doesn’t provide any value and the content is impractical to copy and paste. Only occ config:list system provides redaction (the domain shines through, though).
Funnily enough, it looks like it is meant for posting on github but it isn’t mentioned in any issue template I’ve come across.


Imho, Nextcloud needs a tool for that. Probably, the system report is a good starting point.

It should offer:

  • accessibility
    • in the settings menu (to find it yourself)
    • shareable link (to relieve the already over-burdened admin)
    • maybe a memorable path like /settings/debug_information
    • maybe even a non-admin interface providing user-specific data otherwise limited information
  • control over included information
    • checkbox “don’t strip sensitive information” (which means “strip by default”)
    • include log with options to redact
      • remote IPs
      • usernames
      • maybe prepare for redacting URL paths
      • in-/exclude entries from certain apps
    • maybe app-specific debug info
    • maybe pre-select checkboxes through http parameters
  • options to use the result
    • input field for a quick grab using ctrl-a + ctrl-c
    • send via email
    • share link
      • with or without password
      • configurable expiration (issues often live longer than two weeks)
    • maybe HTML/Markdown, plain HTML, and JSON output formats?

Improvements to the currently included data:

  • ability to redact
    • uname output as it might contain a user and hostname
    • overwrite.cli.url and trusted_domains from config:list
  • lastcron is only a timestamp without the current time as reference. likely want only the amount of seconds since the last call.

Now, I know this is only my perspective and it’s going to be quite a bit of work.
So, because I have a life and a day-job (and I don’t know PHP), I want to know whether any of this is desirable for the rest of the Nextcloud userbase and the various maintainers.

Could you see something like this sitting in the template?

Please provide the output of /settings/system_report?app=files&log.app.files=yes&log.pattern=%28error%7Cwarning%29&format=github_markdown


I have no experience with an no need for debugging the server, all I have is my (possibly wrong) impression that also obtaining debug information from the client could be more end-user friendly.

For the RFC, I can only suggest to differentiate between server and client.
As far as I can tell, the RFC is about the server.