Mjs-warning after Nextcloud Update

Dear Community

My Nexcloud runs in a Docker-Container on an Ubuntu 22.04 Server behind an NGINX-ReverseProxy.
I’m using the docker-image nexcloud:latest, so i think i’m using apache (Sorry, i don’t know, where i can find this information…).
PHP version is 8.2.15
After the Update to 28.0.2, i’m facing the following warning in the system overview:

Could not check for JavaScript support. Please check manually if your webserver serves `.mjs` files using the JavaScript MIME type.

I found on Google a lot of information, but nothing matches my environment…
I think, i have to add the .mjs type to a configuration, but i’m not sure where… Should i add it to my nginx-reverseproxy or to my nexcloud apache?
Can anyone help me with an exact step-by-step manual?

Thanks in advance!

I found in the .htaccess-file in the nexcloud-root the following entry:

AddType text/javascript js mjs

So i think, the apache-config is ok and i have to add an entry in the ngnix-proxymanager. But where and how?

1 Like

In this case, your issue isn’t that .mjs files aren’t functioning (well, they still may not be, but…), but that the check to see if they’re functioning (which was recently added) isn’t working in your environment for some reason.

The check just tries to download a specific file via each of your configured trusted_domains from the Nextcloud Server itself. If the check is failing it’s usually something like:

  • DNS is broken in your Nextcloud container
  • You’re using a self-signed certificate

What happens when you run curl -I https://DOMAIN/apps/settings/js/esm-test.mjs from within your Docker container?

1 Like

Thanks for your answer!
I entered the container with this command:

sudo docker exec -it nextcloud-app-1 bash

Then i ran the curl command to my trusted Domain:

curl -I https://cloud.mydomain.tld/apps/settings/js/esm-test.mjs

This was the result:

curl: (28) Failed to connect to cloud.mydomain.tld port 443 after 130860 ms: Couldn't connect to server

To test, i ran the same command from my docker-host, with the same result.
If i ping cloud.mydomain.tld i recieve an answer from my public ip. So, i think dns works ok…

Do you have any ideas how to resolve the problem?

Since my last Post, i updated to 28.0.3 but the Error is still there. Is there anyone who can help?

I have an additional Information:
My NC-Log is flooded with the following Error:

dns_get_record(): A temporary server error occurred. at /var/www/html/lib/private/Http/Client/DnsPinMiddleware.php#111

So, maybe, the 2 issues are related and there seems definitely to be an dns-issue.
Do i have to define the DNS-Name inside the Docker-Network-Config?

This is my Docker-Network-Config:

networks:
  NET:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.16.2.0/24
          gateway: 172.16.2.1

And this is the Network-Config of the NC-App-Container:

    networks:
      NET:
        ipv4_address: 172.16.2.2

Maybe something like this?:

    networks:
      NET:
        ipv4_address: 172.16.2.2
        hostname: cloud.mydomain.tld

I haven’t tested it yet. Can this anyone confirm?
Thanks in advance!

I have new insights and new questions:
from within the container, this command seems to be ok:

curl -I http://localhost/apps/settings/js/esm-test.mjs

if i change http to https i recieve the following answer:

curl -I https://localhost/apps/settings/js/esm-test.mjs
curl: (7) Failed to connect to localhost port 443 after 0 ms: Couldn't connect to server

So, i think my apache in my nextcloud-container didn’t listen to 443.
I checked it with:

nano /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

There is only a 80 vitualhost, no 443.

I think, that’s the reason why the curl-command to https didn’t work and why the mjs-warning appears… But this is the default Docker-Image without any customization…

what i don’t understand:
DockerHostIP:33602 is mapped to NCAppContainerIP:80
DockerHostIP:80 is mapped to NginxProxyManagerIP:80
DockerHostIP:443 is mapped to NginxProxyManagerIP:443
PublicIP:80 ist forwarded to DockerHostIP:80
PublicIP:443 is forwarded to DockerHostIP:443
Nginx is forwarding all traffic for cloud.mydomain.tld to DockerHostIP:33602 with the Option “Force SSL” and an let’s encrypt certificate.
Why is this config running without an Apache 443 VitualHost?
Is my Configuration running https over Port 80? Is this possible?

Maybe this can help:

Running

curl -I https://nc.domain.tld/apps/settings/js/esm-test.mjs

on my server returned

curl: (6) Could not resolve host: nc.domain.tld

Obviously there was something wrong with my DNS… Having a look into /etc/hosts I noticed that nc.domain.tld was missing there and added

127.0.0.1    nc.domain.tld

Another run of curl -I https://… returned

HTTP/2 200
strict-transport-security: max-age=15552000; includeSubDomains
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
last-modified: Thu, 29 Feb 2024 06:46:24 GMT
etag: "6d-6127f9e2a9000"
accept-ranges: bytes
content-length: 109
vary: Accept-Encoding
cache-control: max-age=15778463
content-type: text/javascript
date: Wed, 13 Mar 2024 12:36:43 GMT
server: Apache/2.4.58 (Debian)

which I take as being alright.

In my browser I reloaded the administrative overview et voilá: I just got rid of the error message.

Thanks for your answer!

With the added hosts entry, the curl-command over http will be ok:

curl -I http://nc.domain.tld/apps/settings/js/esm-test.mjs
HTTP/1.1 200 OK
Date: Wed, 20 Mar 2024 08:52:32 GMT
Server: Apache/2.4.57 (Debian)
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: noindex, nofollow
X-XSS-Protection: 1; mode=block
Last-Modified: Tue, 12 Mar 2024 14:42:10 GMT
ETag: "6d-61377a9c1911a"
Accept-Ranges: bytes
Content-Length: 109
Vary: Accept-Encoding
Cache-Control: max-age=15778463
Content-Type: text/javascript

But with https:// my server returned:

curl -I https://nc.domain.tld/apps/settings/js/esm-test.mjs
curl: (7) Failed to connect to nc.domain.tld port 443 after 0 ms: Couldn't connect to server

So, my problem seems to be that my apache isn’t listen on 443. In the apache config, there is no active 443 VitualHost and this is a non-persistant-data of the docker container (like the hosts-File)… is it possible, that this is a bug of the container-image?
Or:
In my html-path there is a .htaccess-File. This is persistant-data, and maybe there is a mistake inside?

<IfModule mod_headers.c>
  <IfModule mod_setenvif.c>
    <IfModule mod_fcgid.c>
       SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
       RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
    <IfModule mod_proxy_fcgi.c>
       SetEnvIfNoCase Authorization "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>
    <IfModule mod_lsapi.c>
      SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
      RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
  </IfModule>

  <IfModule mod_env.c>
    # Add security and privacy related headers

    # Avoid doubled headers by unsetting headers in "onsuccess" table,
    # then add headers to "always" table: https://github.com/nextcloud/server/pull/19002
    Header onsuccess unset Referrer-Policy
    Header always set Referrer-Policy "no-referrer"

    Header onsuccess unset X-Content-Type-Options
    Header always set X-Content-Type-Options "nosniff"

    Header onsuccess unset X-Frame-Options
    Header always set X-Frame-Options "SAMEORIGIN"

    Header onsuccess unset X-Permitted-Cross-Domain-Policies
    Header always set X-Permitted-Cross-Domain-Policies "none"

    Header onsuccess unset X-Robots-Tag
    Header always set X-Robots-Tag "noindex, nofollow"

    Header onsuccess unset X-XSS-Protection
    Header always set X-XSS-Protection "1; mode=block"

    SetEnv modHeadersAvailable true
  </IfModule>

  # Add cache control for static resources
  <FilesMatch "\.(css|js|mjs|svg|gif|png|jpg|ico|wasm|tflite)$">
    <If "%{QUERY_STRING} =~ /(^|&)v=/">
      Header set Cache-Control "max-age=15778463, immutable"
    </If>
    <Else>
      Header set Cache-Control "max-age=15778463"
    </Else>
  </FilesMatch>

  # Let browsers cache WOFF files for a week
  <FilesMatch "\.woff2?$">
    Header set Cache-Control "max-age=604800"
  </FilesMatch>
</IfModule>

<IfModule mod_php.c>
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>

<IfModule mod_mime.c>
  AddType image/svg+xml svg svgz
  AddType application/wasm wasm
  AddEncoding gzip svgz
  # Serve ESM javascript files (.mjs) with correct mime type
  AddType text/javascript js mjs
</IfModule>

<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>

<IfModule pagespeed_module>
  ModPagespeed Off
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} DavClnt
  RewriteRule ^$ /remote.php/webdav/ [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
  RewriteRule ^ocm-provider/?$ index.php [QSA,L]
  RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

# Clients like xDavv5 on Android, or Cyberduck, use chunked requests.
# When FastCGI or FPM is used with apache, requests arrive to Nextcloud without any content.
# This leads to the creation of empty files.
# The following directive will force the problematic requests to be buffered before being forwarded to Nextcloud.
# This way, the "Transfer-Encoding" header is removed, the "Content-Length" header is set, and the request content is proxied to Nextcloud.
# Here are more information about the issue:
#  - https://docs.cyberduck.io/mountainduck/issues/fastcgi/
#  - https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#troubleshooting-webdav
<IfModule setenvif.c>
  <Location "/remote.php">
    SetEnvIf Transfer-Encoding "chunked" proxy-sendcl=1
  </Location>
</IfModule>

AddDefaultCharset utf-8
Options -Indexes
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /index.php/error/403
ErrorDocument 404 /index.php/error/404
<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
  RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|mjs|svg|gif|png|html|ttf|woff2?|ico|jpg|jpeg|map|webm|mp4|mp3|ogg|wav|flac|wasm|tflite)$
  RewriteCond %{REQUEST_FILENAME} !/core/ajax/update\.php
  RewriteCond %{REQUEST_FILENAME} !/core/img/(favicon\.ico|manifest\.json)$
  RewriteCond %{REQUEST_FILENAME} !/(cron|public|remote|status)\.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v(1|2)\.php
  RewriteCond %{REQUEST_FILENAME} !/robots\.txt
  RewriteCond %{REQUEST_FILENAME} !/(ocs-provider|updater)/
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteCond %{REQUEST_FILENAME} !/richdocumentscode(_arm64)?/proxy.php$
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

or maybe in the config.php?

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'overwritehost' => 'nc.domain.tld',
  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => 'https://nc.domain.tld',
  'trusted_proxies' =>
  array (
    0 => '{IP of the NGNIX Reverse Proxy}',
  ),
  'instanceid' => '{ID}',
  'passwordsalt' => '{Passwordsalt}',
  'secret' => '{secret}',
  'trusted_domains' =>
  array (
    0 => 'nc.domain.tld',
  ),
  'datadirectory' => '/var/www/html/data',
  'skeletondirectory' => '',
  'dbtype' => 'mysql',
  'version' => '28.0.3.2',
  'dbname' => '{dbname}',
  'dbhost' => 'db',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => '{dbuser}',
  'dbpassword' => '{dbpassword}',
  'installed' => true,
  'default_language' => '{default_language}',
  'default_locale' => '{default_locale}',
  'default_phone_region' => '{default_phone_region}',
  'defaultapp' => 'files',
  'allow_user_to_change_display_name' => false,
  'redis' =>
  array (
    'host' => 'redis',
    'password' => '{password}',
    'port' => 6379,
  ),
  'connectivity_check_domains' =>
  array (
    0 => 'www.nextcloud.com',
    1 => 'www.google.com',
  ),
  'maintenance' => false,
  'loglevel' => 2,
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
  'maintenance_window_start' => 1,
);

I hope, there is someone who can troubleshoot my problem… Thanks in advance!

Is HTTPS terminated on your Reverse Proxy or on your Nextcloud App container?

If the former, your DNS entry for nc.domain.tld should point at your RP not 127.0.0.1.

So the answer varies depending on one’s situation.

The bottom line is that the Nextcloud app container needs to have it’s DNS set-up accurately for your environment’s topology. :slight_smile:

Have you taken a closer look into your NGINX configuration file for the Nextcloud installation (usually under /etc/nginx/sites-enabled/…, may be different for Docker container installation)?

I had the same issue/error message regarding the mjs files and could solve it by adding “mjs” into the following line:


location ~ .(?:css|js|mjs|woff|svg|gif)$ {