Closed supr4s closed 6 months ago
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.
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
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?
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.
@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
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
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.
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
@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.
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
@sselka Okay, yeah, I made a mistake, go ahead and try it again. I based it off of main instead of stable29.
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.
I can confirm that i have the same issue here, all worked fine on 28.0.5.
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.
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.
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.
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: "you@name.it"
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
@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.
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.
@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
What would be the best approach to manage this when using nextcloud in a docker image behind a traefik reverse proxy ?
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 !
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?
@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.
@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
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 :(
You can see in the screenshots/logs/info shared from the others in this thread what CODE version is being used
⚠️ This issue respects the following points: ⚠️
Bug description
Hi everyone,
Since updating our Nextcloud server to v29, documents no longer open on Collabora and download directly into the browser. I didn't behave like this before the update.
I have another server which is still in version 28, and the collabora runs from the Nextcloud 28 server. If I point the server that's not working (in NC 29) to the Collabora of the server that is, I get the same behavior. It doesn't even try to open the Collabora: it automatically downloads the file. If, on the other hand, I point my other server (Nextcloud 28) to the Collabora of my server in Nextcloud 29, it works.
Which tells me that it's not a problem on the Collabora side ..
Steps to reproduce
Expected behavior
The document must open in Collabora and not download automatically into the browser.
Installation method
Community Manual installation with Archive
Nextcloud Server version
29
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
When I open a file :