[Bug]: Unable to use Collabora since upgrading to v29 - document downloads in browser and does not open in Collabora

[supr4s]

[Bug]: Unable to use Collabora since upgrading to v29 - document downloads in browser and does not open in Collabora

[elzody]

Update from my side: it looks like I can finally reproduce the issue on one of my machines, there are no browser console errors though so I will dig into some code and see what I can find.

[sselka]

I observe the exact same issue after updating to v29.
The whole setup is similar to v28, where it was working like charm.

I also have the latest collabora container running Collabora Online Development Edition 24.04.2.1 80a6f97

[elzody]

Thanks for the info, that is the part I was thinking, that is legacy code which we should probably not have anymore, since this was fixed in #3645 using the files API. I think maybe I forgot to remove this code, and maybe it is conflicting somehow.

[sselka]

So, I got it. And I actually don't understand why it worked before. However, your hint led me to the right direction!

The given snippet is not helpful in my particular case, as I already had the include mime.types within the http block.

However, the issue was the missing definition for the mjs files, so the relevant change was changing location ~* \.(?:css|js)$ { to location ~* \.(?:css|js|mjs|svg|gif|png|jpg|ico|wasm|tflite|map|ogg|flac)$ {

So for me this issues is solved, even though i do not know why it was working before and just changed within that particular update to NC29.

I make a wild guess: the viewer app has changed from js files to mjs files.

Thanks so much @elzody and sorry for bothering as this is definitely a mistake up to my misconfiguration.

[supr4s]

Hi @elzody ,

I can confirm that it now works. It was indeed a misconfiguration and not a bug. I didn't look in the devtools, mea culpa!

For my part, the configuration that corrected it :

/etc/nginx/mime.types
[...]
application/javascript                js mjs;

And as mentionned bu @sselka :

location ~* \.(?:css|js|mjs|svg|gif|png|jpg|ico|wasm|tflite|map|ogg|flac)$

Thanks everyone !

[peseotni]

same problem here.
I installed collabora on a server and nextcloud finds the server but the files do not open but download them, after upgrading nextcloud to 29.

[elzody]

Usually in my experience this is due to the viewer app not being installed or working improperly. In the screenshots from @peseotni it also indicates the viewer app may not be installed. I do see it in the list of your enabled apps, so maybe just double check and see. I can't reproduce it on my end.

What type of files are you trying to open?

[sselka]

Do you mean this viewer app? @elzody

For Collabora and richdocuments, the viewer app is not needed. At least it wasn't until NC28 and the README tells similar (Current support: Images, Videos).

However, i tried to open *.ods and *.odt files as usual. Still downloading them.

[elzody]

@sselka By default the viewer is for those filetypes, yeah, but you can also hook into it with other apps. For example in richdocuments it registers a handler for office files and uses the viewer to then open a Vue component. So if the viewer is working properly on your end this is definitely a weird issue, I will keep digging

Do you have any other logs you could share

[sselka]

Just to be sure, that this is not realted to the viewer, I also checked that on my instance.
See the list:

[http@493b439d6009 nextcloud]$ php-legacy occ app:list
Enabled:
  - activity: 2.21.1
  - admin_audit: 1.19.0
  - calendar: 4.7.4
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contacts: 6.0.0
  - contactsinteraction: 1.10.0
  - dashboard: 7.9.0
  - dav: 1.30.1
  - deck: 1.13.0
  - federatedfilesharing: 1.19.0
  - federation: 1.19.0
  - files: 2.1.0
  - files_downloadlimit: 2.0.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - firstrunwizard: 2.18.0
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - nextcloud_announcements: 1.18.0
  - notifications: 2.17.0
  - oauth2: 1.17.0
  - password_policy: 1.19.0
  - photos: 2.5.0
  - polls: 6.3.0
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - recommendations: 2.1.0
  - richdocuments: 8.4.2
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - support: 1.12.0
  - survey_client: 1.17.0
  - systemtags: 1.19.0
  - text: 3.10.0
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - twofactor_totp: 11.0.0-dev
  - updatenotification: 1.19.1
  - user_status: 1.9.0
  - viewer: 2.3.0
  - weather_status: 1.9.0
  - workflowengine: 2.11.0

I checked for further logs. The one and only match I find is that one in my javascript console when refreshing the the browser on whatever files path (https://mydomain.tld/apps/files/files/1337?dir=/Wahtever) which looks like a good starting point to dig in:

Uncaught TypeError: Cannot read properties of undefined (reading 'openWith')
    at richdocuments-viewer.js?v=e408d918-39:2:1716450
    at richdocuments-viewer.js?v=e408d918-39:2:1717109
    at richdocuments-viewer.js?v=e408d918-39:2:1717113

See the attached screenshot from the Browser sources after clicking richdocuments-viewer.js?v=e408d918-39:2:1717113

[sselka]

Happy to hear that you can narrow it down. If you need further information or checkups, I am happy to test asap on my testing stage

[elzody]

@sselka Have you tried yet to do a hard refresh using Ctrl + Shift + R? Also, I removed the legacy code here in this branch of the richdocuments app, if you are able to clone it and test, that would be great.

[sselka]

I am not at all much into the code of nextcloud, but i build the richdocuments app and deployed it to my testing stage. The richdocuments app got disabled. So i went as admin in order to enable it, which wasn't possible. The enable button was disabled. So I removed the disabled flag from the button with the development tools and clicked it, but I get faced with

I assume there's somewhere a check for the running NC version? Its the latest: 29.0.0.19

[elzody]

@sselka Okay, yeah, I made a mistake, go ahead and try it again. I based it off of main instead of stable29.

[sselka]

So i tried it and the issue is the same. There is no more that error message in the javascript console, but the files are still getting downloaded. :(
Collabora is not loading.

[hardwareadictos]

I can confirm that i have the same issue here, all worked fine on 28.0.5.

[sselka]

Some additional insight for the contributors @elzody and @juliushaertl
For the sake of giving it a try, i installed richdocuments in version 8.3.2 to NC29, as this was the last running combination with NC28. In order to get it running, I changed the appinfo.xml accordingly:

	<dependencies>
		<nextcloud min-version="28" max-version="29"/>
	</dependencies>

However, that was not helping. The documents are still getting downloaded and not opened with Collabora online within the browser.

[elzody]

The next steps would be to try accessing the document from an incognito/private browser window, else clear your browser's cache and storage. I actually can't reproduce in the end, it turns out I just didn't have the viewer app installed & enabled on that machine (which is actually the main reason this issue occurs, so I stupidly fell victim to it).

There is nothing I can see in the richdocuments code base which changed that might have caused it, at least that I can see. If nothing I said above works for you all, then I will bring it up with the rest of my team and we can go from there.

Sorry for being so far unhelpful, and for the issues you are experiencing.

[sselka]

I also just started again in a private window, all cleaned on my test stage. I get quite a lot of errors in the console, also related to the Viewer. However, that's what i get on the shell:

[http@c2b6e853ec28 nextcloud]$ php-legacy occ app:enable viewer
viewer already enabled

For more clear information, here are my configs:

traefik.yml (reverse proxy)

# Logging configuration
log:
  level: WARN

api:
  dashboard: false
providers:
  docker:
    network: backend
    exposedByDefault: false
    endpoint: "unix:///var/run/docker.sock"   # Listen to the UNIX Docker socket
    swarmModeRefreshSeconds: 15               # Defines the polling interval (in seconds) in Swarm Mode.
  file:
    filename: "/traefik-dynamic-config.yml"  # Link to the dynamic configuration
    watch: true                               # Watch for modifications
  providersThrottleDuration: 10
entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: "websecure"
          scheme: "https"
          permanent: true
  websecure:
    address: ":443"
  streaming:
    address: ":64738/udp"
    udp:
      timeout: "10s"
  other:
    address: ":64738"
certificatesResolvers:
    leresolver:
      acme:
        caServer: "https://acme-v02.api.letsencrypt.org/directory"
        email: "[email protected]"
        storage: "/acme.json"
        httpChallenge:
          entrypoint: web

`traefik-dynamic-config.yml

http:
  middlewares:
    default:
      chain:
        middlewares:
          - secureHeaders
    defaultWithOriginReferrer:
      chain:
        middlewares:
          - originReferrer
          - secureHeaders
    secureHeaders:
      headers:
        referrerPolicy: "no-referrer"
        featurePolicy: "geolocation 'none'; midi 'none'; sync-xhr 'none'; microphone 'none'; camera 'none'; magnetometer 'none'; gyroscope 'none'; speaker 'none'; fullscreen 'self'; payment 'none'"
        sslTemporaryRedirect: true
        sslForceHost: true
        customFrameOptionsValue: "SAMEORIGIN"
        addVaryHeader: true
        sslRedirect: true
        frameDeny: true
        stsIncludeSubdomains: true
        stsPreload: true
        stsSeconds: "31536000"
        contentTypeNosniff: true
        accessControlMaxAge: "31536000"
        accessControlAllowOriginList: "https://domain.tld, https://another-domain.tld, https://*.doimain.tld, https://*.another-domain.tld"
        permissionsPolicy: "camera=(), microphone=(), geolocation=(), payment=(), usb=(), vr=()"
        accessControlAllowMethods: "GET, POST, PUT, DELETE, PROPFIND, HEAD"
    originReferrer:
      headers:
        referrerPolicy: "origin"
    collaboraHeaders:
      headers:
        customResponseHeaders:
          user-agent: "<deleted>"
          x-content-type-options: ""
          x-xss-protection: ""
          referrer-policy: ""
          content-security-policy: ""
tls:
  options:
    default:
      minVersion: VersionTLS12
      cipherSuites:
        # ciphers for TLSv1.2
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
        # ciphers for TLSv1.3
        - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
    tlsv13only:
      minVersion: VersionTLS13
    modern:
      minVersion: "VersionTLS13"                          # Minimum TLS Version
      sniStrict: true                                     # Strict SNI Checking
routers:
  servicename:
    rule: "(Host(`domain.tld`) || Host(`www.domain.tld`))"
    middlewares:
      - default
    service: servicename

services:
  servicename:
    loadBalancer:
      servers:
        - url: "http://mycontainername:80"

And for the sake of completeness, here is the nginx.conf of my nextcloud container:

nginx.conf (nextcloud)

user http;
worker_processes auto;
worker_cpu_affinity auto;
pcre_jit on;

events {
  worker_connections 2048;
}

http {
  include mime.types;
  default_type application/octet-stream;
  sendfile on;
  tcp_nopush on;
  aio threads;
  server_tokens off; # Security: Disables nginx version in error messages and in the “Server” response header field.
  charset utf-8; # Force usage of UTF-8
  index index.php index.html index.htm;

  upstream php-handler {
    server unix:/run/php-fpm-legacy/php-fpm.sock;
  }

  server {
    listen 80;
    server_name domain.tld;

    root /usr/share/webapps/nextcloud/;

    location = /robots.txt {
      deny all;
      log_not_found off;
      access_log off;
    }

    # The following 2 rules are only needed for the user_webfinger app.
    # Uncomment it if you're planning to use this app.
    #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
    # last;

    location = /.well-known/carddav {
      return 301 $scheme://$host/remote.php/dav;
    }
    location = /.well-known/caldav {
      return 301 $scheme://$host/remote.php/dav;
    }

    location ~ /.well-known/acme-challenge {
      allow all;
    }

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    # Disable gzip to avoid the removal of the ETag header
    gzip off;

    # Uncomment if your server is build with the ngx_pagespeed module
    # This module is currently not supported.
    #pagespeed off;

    error_page 403 /core/templates/403.php;
    error_page 404 /core/templates/404.php;

    location / {
      rewrite ^ /index.php$uri;
    }

    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
      deny all;
    }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
      deny all;
    }

    location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
      include fastcgi_params;
      fastcgi_split_path_info ^(.+\.php)(/.*)$;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      #Avoid sending the security headers twice
      fastcgi_param modHeadersAvailable true;
      fastcgi_param front_controller_active true;
      fastcgi_pass php-handler;
      fastcgi_intercept_errors on;
      fastcgi_request_buffering off;
    }

    location ~ ^/(?:updater|ocs-provider)(?:$|/) {
      try_files $uri/ = 404;
      index index.php;
    }

    # Adding the cache control header for js and css files
    # Make sure it is BELOW the PHP block
    location ~* \.(?:css|js)$ {
      try_files $uri /index.php$uri$is_args$args;
      add_header Cache-Control "public, max-age=7200";
      # Optional: Don't log access to assets
      access_log off;
    }

    location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
      try_files $uri /index.php$uri$is_args$args;
      # Optional: Don't log access to other assets
      access_log off;
    }
  }
}

All the configs have not been changed for quite a while now. After several upgrades.

Hope that helps

[elzody]

@sselka I found out some more information with the help of a colleague -- for that error specifically, you have to change your nginx config to include the following:

# Set .mjs and .wasm MIME types
# Either include it in the default mime.types list
# and include that list explicitly or add the file extension
# only for Nextcloud like below:
include mime.types;
types {
    text/javascript js mjs;
    application/wasm wasm;
}

This is outlined here for nginx, which should fix the JS modules errors in the browser console. This may also fix the viewer issue that is causing the documents to be downloaded, since the initial JS modules required for such things to work may not be getting loaded.

Let me know if this helps at all.

[elzody]

@sselka No problem, happy it was figured out! Now we know :)

I will also ask that others to check their config as well, since they also use nginx. And for anyone else reading this in the future, it could be a configuration issue with your web server if you are experiencing the same symptoms.

For Apache, you can check the docs here, and for nginx you can check here.

@supr4s Could you confirm if you get it working via sselka's method or by making sure your config correctly conforms to that of the documentation? Once confirmed I will mark as closed

[jmchantrein]

What would be the best approach to manage this when using nextcloud in a docker image behind a traefik reverse proxy ?

[elzody]

What would be the best approach to manage this when using nextcloud in a docker image behind a traefik reverse proxy ?

I'm not familiar with traefik, but from what I can tell you can't map mimetypes in the configuration like you can with something like nginx. This would require further research, and for now I am going to close the issue.

Maybe something here would help you?

[hardwareadictos]

@sselka No problem, happy it was figured out! Now we know :)

I will also ask that others to check their config as well, since they also use nginx. And for anyone else reading this in the future, it could be a configuration issue with your web server if you are experiencing the same symptoms.

For Apache, you can check the docs here, and for nginx you can check here.

@supr4s Could you confirm if you get it working via sselka's method or by making sure your config correctly conforms to that of the documentation? Once confirmed I will mark as closed

Well i suspect we use the same nginx.conf structure conformed by an http block but i applied your fix and i still et the same issue, using docker here.

[elzody]

@hardwareadictos I would suggest taking a look at the nginx config I linked there, the config seems to have changed a bit in recent versions so just make sure it's doing what it should be, using the docs as a reference. That's my suggestion for now

[hardwareadictos]

would be nice to know which code version are people using, just reverted my container backup to original version (without the suggested nginx configs), updated to 24.04.3.1.1 and documents are now opening fine on nextcloud :(

[elzody]

You can see in the screenshots/logs/info shared from the others in this thread what CODE version is being used