[Bug]: Logging display console errors and white-blank screen

[geraldurbas]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Opening the Logging Screen shows errors. After a few seconds only a white blank is displayed.
JS Error thrown:

Steps to reproduce

1. Open Log in Admin view; wait a second

Expected behavior

Log entries keep visible

Installation method

Other Community project

Operating system

Debian/Ubuntu

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

No response

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "150.100.0.36",
            "nextcloud.crossmediapool.at",
            "nextcloud-int.crossmediapool.at"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "24.0.7.1",
        "overwrite.cli.url": "https:\/\/nextcloud.crossmediapool.at",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "memcache.local": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0
        },
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "theme": "",
        "debug": true,
        "loglevel": 3,
        "default_phone_region": "AT",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "default_language": "de",
        "default_locale": "de_DE",
        "force_language": "de",
        "force_locale": "de_DE",
        "mail_smtpsecure": "tls",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

Enabled:
  - accessibility: 1.10.0
  - activity: 2.16.0
  - admin_audit: 1.14.0
  - appointments: 1.14.3
  - bookmarks: 11.0.4
  - bruteforcesettings: 2.4.0
  - calendar: 3.5.2
  - circles: 24.0.1
  - cloud_federation_api: 1.7.0
  - cms_pico: 1.0.20
  - comments: 1.14.0
  - contacts: 4.2.2
  - contactsinteraction: 1.5.0
  - dashboard: 7.4.0
  - dav: 1.22.0
  - deck: 1.7.3
  - duplicatefinder: 0.0.15
  - emlviewer: 1.0.4
  - external: 4.0.1
  - externalportal: 1.0.2
  - federatedfilesharing: 1.14.0
  - federation: 1.14.0
  - files: 1.19.0
  - files_external: 1.16.1
  - files_fulltextsearch: 24.0.1
  - files_markdown: 2.3.6
  - files_mindmap: 0.0.27
  - files_pdfviewer: 2.5.0
  - files_reader: 1.5.3
  - files_rightclick: 1.3.0
  - files_sharing: 1.16.2
  - files_trashbin: 1.14.0
  - files_versions: 1.17.0
  - files_videoplayer: 1.13.0
  - fileslibreofficeedit: 1.1.0
  - firstrunwizard: 2.13.0
  - integration_github: 1.0.4
  - logreader: 2.9.0
  - lookup_server_connector: 1.12.0
  - nextcloud_announcements: 1.13.0
  - notes: 4.5.1
  - notifications: 2.12.1
  - oauth2: 1.12.0
  - officeonline: 1.1.3
  - password_policy: 1.14.0
  - photos: 1.6.0
  - privacy: 1.8.0
  - provisioning_api: 1.14.0
  - quicknotes: 0.8.1
  - quota_warning: 1.15.0
  - recommendations: 1.3.0
  - registration: 1.5.0
  - richdocuments: 6.3.1
  - richdocumentscode: 22.5.802
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - sharebymail: 1.14.0
  - snappymail: 2.21.4
  - support: 1.7.0
  - survey_client: 1.12.0
  - systemtags: 1.14.0
  - tables: 0.2.1
  - tasks: 0.14.5
  - text: 3.5.1
  - theming: 1.15.0
  - twofactor_backupcodes: 1.13.0
  - updatenotification: 1.14.0
  - user_status: 1.4.0
  - viewer: 1.8.0
  - weather_status: 1.4.0
  - workflowengine: 2.6.0
Disabled:
  - afterlogic: 2.0.4
  - approval: 1.0.10
  - encryption
  - files_automatedtagging: 1.14.0
  - files_retention: 1.13.2
  - files_trackdownloads: 1.11.0
  - fulltextsearch: 23.0.0
  - groupfolders: 12.0.2
  - mail: 1.14.3
  - messagevault: 1.0.0
  - onlyoffice: 7.5.8
  - rainloop: 7.2.6
  - recognize: 2.2.1
  - spreed: 14.0.6
  - user_ldap
  - user_retention: 1.7.2
  - wopi: 3.5.11
  - workflow_pdf_converter: 1.9.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

No response

[solracsf]

I believe this white-screen happens when a new entry is added to the log. If this helps debugging.

[geraldurbas]

I believe this white-screen happens when a new entry is added to the log. If this helps debugging.

Correct - the white screen happens when a new error is generated.

[Bockeman]

@solracsf marked nextcloud/server#35659 as a duplicate (correctly -- apologies: I do not know why my searches did not throw up this one). I am on later versions of most apps, OS, kernel, etc. so it may be worth refering back to this.

Note for me the logging page goes blank immediately, I just get a flash of what I expect to see. This is different from what @geraldurbas reports.

@kesselb asked for more info
nextcloud/server#35659 (comment)

After a page refresh a copy/paste from the console is:

10:57:27.008 JQMIGRATE: Migrate is installed, version 3.4.0 jquery-migrate.min.js:2:698
10:57:27.412 [DEBUG] unified-search: Unified Search initialized with the following providers 
Object { 0: {?}, 1: {?}, 2: {?}, 3: {?}, 4: {?}, 5: {?}, 6: {?}, 7: {?}, level: 0, app: "unified-search", ? }
?
0: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
??
__ob__: Object { shallow: false, mock: false, vmCount: 0, ? }
??
id: 
??
name: 
??
order: 
??
<get id()>: function get()??
<set id()>: function set(t)??
<get name()>: function get()??
<set name()>: function set(t)??
<get order()>: function get()??
<set order()>: function set(t)??
<prototype>: Object { ? }
?
1: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
2: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
3: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
4: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
5: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
6: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
7: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
app: "unified-search"
?
level: 0
?
uid: "admin"
?
<prototype>: Object { ? }
??
__defineGetter__: function __defineGetter__()
??
__defineSetter__: function __defineSetter__()
??
__lookupGetter__: function __lookupGetter__()
??
__lookupSetter__: function __lookupSetter__()
??
__proto__: 
??
constructor: function Object()
??
hasOwnProperty: function hasOwnProperty()
??
isPrototypeOf: function isPrototypeOf()
??
propertyIsEnumerable: function propertyIsEnumerable()
??
toLocaleString: function toLocaleString()
??
toString: function toString()
??
valueOf: function valueOf()
??
<get __proto__()>: function __proto__()
??
<set __proto__()>: function __proto__()
ConsoleLogger.js:52:10
10:57:27.573 Got notification data NotificationsApp.vue:384
10:57:27.573 Polling interval updated to 30000 NotificationsApp.vue:421
10:57:57.546 No new notification data received NotificationsApp.vue:389
10:57:57.547 Polling interval updated to 30000 NotificationsApp.vue:421
10:58:27.560 No new notification data received NotificationsApp.vue:389
10:58:27.560 Polling interval updated to 30000 NotificationsApp.vue:421
10:58:57.564 No new notification data received NotificationsApp.vue:389
10:58:57.564 Polling interval updated to 30000 NotificationsApp.vue:421
10:59:27.553 No new notification data received NotificationsApp.vue:389
10:59:27.554 Polling interval updated to 30000 NotificationsApp.vue:421
10:59:57.571 No new notification data received NotificationsApp.vue:389

which to me looks pretty blank (as in lots of calls with default/blank parameters).

How can I help drill this down to more useful information?

[pixel8383]

I am running Nextcloud 25.0.2 on several servers and one of them is facing the same issue. I don't have LDAP authentication active on that server (answering to this comment) so it seems to be unrelated to that specific plugin.

[unalignedcoder]

Same problem here. Nextcloud 25.0.3.

The debug file exists, and it has the right permissions. It is correctly configured in the config file.

It remains empty, and the logging interface is empty as well.

When I run php occ log:manage it returns this:

{"reqId":"wsrPsOz03jSNXMvU9Nq5","level":1,"time":"2023-01-19T13:34:12+00:00","remoteAddr":"","user":"--","app":"related_resources","method":"","url":"--","message":"Could not resolve OCA\\Circles\\CirclesManager! Class \"OCA\\Circles\\CirclesManager\" does not exist","userAgent":"--","version":"25.0.3.2","data":{"app":"related_resources"}}
{"reqId":"wsrPsOz03jSNXMvU9Nq5","level":1,"time":"2023-01-19T13:34:12+00:00","remoteAddr":"","user":"--","app":"admin_audit","method":"","url":"--","message":"Console command executed: log:manage","userAgent":"--","version":"25.0.3.2","data":{"app":"admin_audit"}}
Enabled logging backend: file
Log level: Info (1)
Log timezone: UTC

Changing the Log Level in the config file is reflected accordingly in the message. I don't know why the Circles app is referred to. It is disabled. If I enable it, the first part disappears. If I disable the Audting/Logging app, the second part disappears. Either way the log file stays empty, so I don't think this is related.

Also, changing the debug level within the web interface is not reflected in the config file. Weird.

[dbolton]

Any improvement if you change the log level from Info (1) to Warn (2)? You can chance this by editing config/config.php in the nextcloud folder.

[Bockeman]

Checked again on 25.0.2, no blank-white display for me any longer
(I don't know what happened to resolve the issue).
Upgraded to 25.0.3, no issue for me.

[joshtrichards]

@Fred-Zweig @loddi @benklaasen Please refer to the NC27 Admin Manual release notes and/or other closed issues in this repo. Your configuration is not up-to-date for handling of .mjs files. This is not a bug, but a local config matter with your web server. In addition, it's unrelated to the Issue you're commenting on (this one), as the log reader in NC25 versus NC28 was a complete rewrite on the front end.

Follow-up on the Nextcloud Help Forum if needed - https://help.nextcloud.com

[bernd-wechner]

I have the same problem. Just saying:

Nextcloud Hub 7 (28.0.1)

$ php --version
PHP 8.1.2-1ubuntu2.14 (cli) (built: Aug 18 2023 11:41:11) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.2-1ubuntu2.14, Copyright (c), by Zend Technologies
    with Xdebug v3.1.2, Copyright (c) 2002-2021, by Derick Rethans

I can see the log file in the data director as nextcloud.log. It looks recently updated and is about 10MB in size.

I don't see any console errors in the browser though.

[joshtrichards]

@bernd-wechner Your situation is likely entirely unrelated to the reported issue here. NC28's logreader has a completely rewritten front-end. Chances are you're encountering one of the configuration/local environment matters that have hit NC28 users:

• ad blocker browser extension (many have had false positives blocking NC28's new logreader)
• mjs file handling missing from web server config (see the NC27 upgrade docs where this was functionality was first required though logreader didn't require it until NC28)

[Fred-Zweig]

@joshtrichards I knew that my issue was not identical with the one described in the opening post, yet it was similar and I didn't want to open a separate issue. Anyway, I can confirm now that adding

    include /etc/nginx/mime.types;
    types { text/javascript js mjs; }

to my Nginx configuration as shown here, solved the problem: now the Logging page loads correctly and so does the Activity page. Yet, I don't consider this as a proper solution. The best solution would have been to implement all the functionalities added via the .mjs files using simple .js files. We shouldn't let ourselves be forced by Node.js developers (paid by Google) to adopt new file extensions.

[bernd-wechner]

@bernd-wechner Your situation is likely entirely unrelated to the reported issue here. NC28's logreader has a completely rewritten front-end. Chances are you're encountering one of the configuration/local environment matters that have hit NC28 users:

* ad blocker browser extension (many have had false positives blocking NC28's new logreader)

* mjs file handling missing from web server config (see the NC27 upgrade docs where this was functionality was first required though logreader didn't require it until NC28)

Spot on. I added ".mjs" to my mimetypes configuration as "application/javascript" and the Forms app came good! Turns out .mjs is an ES6 extensions and seemingly hasn't made it into all default mime type declarations and configs yet. But logging has returned! (as has Forms, it too was impacted)

[bernd-wechner]

Yet, I don't consider this as a proper solution

But is a proper solution. Welcome to the web. Things inch forwards. ES6 introduced a new module packaging extensions and not all webservers have absorbed it in their mime default configurations yet. PITA, yes. Proper solution, most definitely. Better transition desirable - probably (as in the Administration Overview Tests that run could check for .mjs support and report if missing, given this is a likely issue folk encounter in upgrading).

[joshtrichards]

Better transition desirable - probably (as in the Administration Overview Tests that run could check for .mjs support and report if missing, given this is a likely issue folk encounter in upgrading).

nextcloud/server#42436 :-)

Better late than never! Just three days old. Backported too so it'll be in upcoming v28.0.2.

[Fred-Zweig]

Things inch forwards. ES6 introduced a new module packaging extensions and not all webservers have absorbed it in their mime default configurations yet.

Things are believed to inch forwards. It doesn't mean they do. Have you read this thread, or asked yourself why Nginx developers were still reluctant to add the new .mjs file extension to the list of default MIME types supported by Nginx ? Even today, the latest version of Nginx doesn't officially support .mjs files. All the functionalities added via .mjs files could have been added using simple .js files if someone took the time to do it. If tomorrow, some Node.js deveopers paid by Google decide to invent a new extension, let's say .djs, would you eagerly change your Nginx configuration to adopt the new file extension just because it was imposed by Google ? I wouldn't. Maybe you should first investigate who is paying and controlling the developers who promote the sub-optimal runtime environment called Node.js, before going with the flow.

[bernd-wechner]

Things inch forwards. ES6 introduced a new module packaging extensions and not all webservers have absorbed it in their mime default configurations yet.

Things are believed to inch forwards. It doesn't mean they do. Have you read this thread, or asked yourself why Nginx developers were still reluctant to add the new .mjs file extension to the list of default MIME types supported by Nginx ? Even today, the latest version of Nginx doesn't officially support .mjs files. All the functionalities added via .mjs files could have been added using simple .js files if someone took the time to do it. If tomorrow, some Node.js deveopers paid by Google decide to invent a new extension, let's say .djs, would you eagerly change your Nginx configuration to adopt the new file extension just because it was imposed by Google ? I wouldn't. Maybe you should first investigate who is paying and controlling the developers who promote the sub-optimal runtime environment called Node.js, before going with the flow.

Well, I added it as 'application/javascript' and all is fine. I don't use nginx, but lighttpd (as I don't need a sluggish dinosaur like Apache, and prefer freeware that favoured by my gateway than freemium software where possible and lighttpd performs on par with nginx in scaleability and resource efficiency).

But as @joshtrichards points out, Nextcloud is adding a check to the Overview page (and I concur, better late than never).

I'm not here to judge what Noe.JS do or nginx do or Nextcloud for that matter, and suggest humbly that judgement as a rule isn't constructive to any part of the FOSS world, and best replaced by humble suggestions. Fret not, we all venture into judgement on our darkest, most frustrated days ;-).

Given it was easy to fix all is good and I'm pleased the nextcloud will check and report in future (that is something of import as I don't mind fixing problems if they are easily diagnosed and fixed, but mysterious failures with no easy clues are time-consuming bothers I grant.