NC23 Doesn't recognize open documents to launch via collabra

[dkebler]

Describe the bug
just spun up nc23 the other day via docker containers(fpm-nginx with caddy reverse proxy on host). It’s running fine

It has collabra core and collabra app included. Both are enabled and I’ve selected the core in the settings.

NC seems to know the file types (e.g. .odt) as when you make a new file that is a choice.

But if you then open the file (in the browser ui, single click) instead of opening collabra libreoffice with that file it just wants to download it like it would any unknown file type.

Note: Markdown works. if you click on .md file it opens in the markdown editor so other file types are opening their app

Not sure what setting/setup I’m missing here but it’s not working “out of the box”.

To Reproduce

See above. spin up nc23 docker. Enable collabra core, create a odt document, attempt to open doucment, NC tries to download document instead of opening embeded collarbra with the doucment

Expected behavior
Should open the odt document in collabra (libreoffiece) app embeded in NC web UI like other know document types (e.g. .md)

Screenshots
See above for screenshoot If applicable, add screenshots to help explain your problem.

Client details:

• OS: linux
• • Browser chrome latest

Server details

Operating system: Linux

Web server: caddy reverse proxy on docker host

Database:
MYSQL in docker

PHP version:
php-fpm in docker

*Nextcloud version:
23 - fpm-nginx docker

Version of the richdocuments app
5.0.1

Version of Collabora Online
21.11.103 (built in)

SERVER LOG when trying to open doucment

{"reqId":"XNZ73T9phdt96ekgqBMg","level":3,"time":"2022-02-07T19:41:52+00:00","remoteAddr":"10.0.0.1","user":"admin","app":"PHP","method":"GET","url":"/core/preview?fileId=4432&c=5bb83ddbdd1ddcefefe200506920b238&x=250&y=250&forceIcon=0&a=0","message":"ZipArchive::open(): Using empty file as ZipArchive is deprecated at /var/www/html/lib/private/Archive/ZIP.php#50","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36","version":"23.0.0.10","exception":{"Exception":"Error","Message":"ZipArchive::open(): Using empty file as ZipArchive is deprecated at /var/www/html/lib/private/Archive/ZIP.php#50","Code":0,"Trace":[{"function":"onError","class":"OC\\Log\\ErrorHandler","type":"::","args":[8192,"ZipArchive::open(): Using empty file as ZipArchive is deprecated","/var/www/html/lib/private/Archive/ZIP.php",50]},{"file":"/var/www/html/lib/private/Archive/ZIP.php","line":50,"function":"open","class":"ZipArchive","type":"->","args":["/tmp/oc_tmp_EgkPPE",1]},{"file":"/var/www/html/lib/private/Preview/Bundled.php","line":41,"function":"__construct","class":"OC\\Archive\\ZIP","type":"->","args":["/tmp/oc_tmp_EgkPPE"]},{"file":"/var/www/html/lib/private/Preview/OpenDocument.php","line":44,"function":"extractThumbnail","class":"OC\\Preview\\Bundled","type":"->","args":[{"__class__":"OC\\Files\\Node\\File"},"Thumbnails/thumbnail.png"]},{"file":"/var/www/html/lib/private/Preview/GeneratorHelper.php","line":62,"function":"getThumbnail","class":"OC\\Preview\\OpenDocument","type":"->","args":[{"__class__":"OC\\Files\\Node\\File"},4096,4096]},{"file":"/var/www/html/lib/private/Preview/Generator.php","line":245,"function":"getThumbnail","class":"OC\\Preview\\GeneratorHelper","type":"->","args":[{"__class__":"OC\\Preview\\OpenDocument"},{"__class__":"OC\\Files\\Node\\File"},4096,4096]},{"file":"/var/www/html/lib/private/Preview/Generator.php","line":140,"function":"getMaxPreview","class":"OC\\Preview\\Generator","type":"->","args":[{"__class__":"OC\\Files\\SimpleFS\\SimpleFolder"},{"__class__":"OC\\Files\\Node\\File"},"application/vnd.oasis.opendocument.text",""]},{"file":"/var/www/html/lib/private/Preview/Generator.php","line":109,"function":"generatePreviews","class":"OC\\Preview\\Generator","type":"->","args":[{"__class__":"OC\\Files\\Node\\File"},[{"width":250,"height":250,"crop":true,"mode":"fill"}],"application/vnd.oasis.opendocument.text"]},{"file":"/var/www/html/lib/private/PreviewManager.php","line":212,"function":"getPreview","class":"OC\\Preview\\Generator","type":"->","args":[{"__class__":"OC\\Files\\Node\\File"},250,250,true,"fill",null]},{"file":"/var/www/html/core/Controller/PreviewController.php","line":169,"function":"getPreview","class":"OC\\PreviewManager","type":"->","args":[{"__class__":"OC\\Files\\Node\\File"},250,250,true,"fill"]},{"file":"/var/www/html/core/Controller/PreviewController.php","line":142,"function":"fetchPreview","class":"OC\\Core\\Controller\\PreviewController","type":"->","args":[{"__class__":"OC\\Files\\Node\\File"},250,250,false,false,"fill"]},{"file":"/var/www/html/lib/private/AppFramework/Http/Dispatcher.php","line":217,"function":"getPreviewByFileId","class":"OC\\Core\\Controller\\PreviewController","type":"->","args":[4432,250,250,false,false,"fill"]},{"file":"/var/www/html/lib/private/AppFramework/Http/Dispatcher.php","line":126,"function":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->","args":[{"__class__":"OC\\Core\\Controller\\PreviewController"},"getPreviewByFileId"]},{"file":"/var/www/html/lib/private/AppFramework/App.php","line":157,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->","args":[{"__class__":"OC\\Core\\Controller\\PreviewController"},"getPreviewByFileId"]},{"file":"/var/www/html/lib/private/Route/Router.php","line":302,"function":"main","class":"OC\\AppFramework\\App","type":"::","args":["OC\\Core\\Controller\\PreviewController","getPreviewByFileId",{"__class__":"OC\\AppFramework\\DependencyInjection\\DIContainer"},{"_route":"core.Preview.getPreviewByFileId"}]},{"file":"/var/www/html/lib/base.php","line":1006,"function":"match","class":"OC\\Route\\Router","type":"->","args":["/core/preview"]},{"file":"/var/www/html/index.php","line":36,"function":"handleRequest","class":"OC","type":"::","args":[]}],"File":"/var/www/html/lib/private/Log/ErrorHandler.php","Line":92,"CustomMessage":"--"}}

Browser log

[neufeind]

This happened for me with Nextcloud 23.0.2 after moving from PHP 7.4 to 8.0. Switching back (and clearing cookies, logging in etc.) the office-documents opened with Collabora again. Most details between 7.4 and 8.0 (like opcache, APCu, ...) seem to be identical. Disabling apcu on 8.0 also didn't help.

[juliushaertl]

Any further errors in the Nextcloud log? The one shared above does not seem to be related to the document opening or richdocuments.

[dkebler]

no nothing related. I've cleared the log, attempted to open the file and then looked at the log again. What I posted was it. As far as NC is concerned there is no error to log.

I'm running via fpm with nginx proxy (one of the supported docker service setups) https://github.com/nextcloud/docker/tree/master/23/fpm-alpine

I really think it's a mimetype problem. When you run the cursor over a known file type you should see something like
https://files.xxxx.org/apps/files/?dir=/somedir&openfile=54xx
but instead it shows the webdav url which NC does for ALL unknown file types.
https://files.xxxx.org/remote.php/webdav/somedir/afile.odt

even if I figure out the file id of the odt file and paste this app url in it changes back to the webdav url and attempts to download the file.

I douible checked and the nginx container has the right mime files for open documents and the nextcloud has correct mime type in it's two files. So that is not the issue.

Here is my docker compose file. I did not change the nginx.conf file from the repo. Externally I run Caddy to https reverse proxy the ngiinx container's exposed port.

I just also upgraded to 23.02 and the issue remains. Also very latest core and richdocuments too.
This setup is running fine. Alll other apps that can open files in the browser (like markdown and pdf) are working fine.

Maybe someone can spin this up and see if they get the same issue? I'm wondering it is only when used fpm/nginx vs apache?

version: '3'

services:
  db:
    image: mariadb:10.5
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
    volumes:
      - db:/var/lib/mysql
    env_file:
      - db.env

  redis:
    image: redis:alpine
    restart: always

  app:
    image: nextcloud:fpm-alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_HOST=db
      - REDIS_HOST=redis
    env_file:
      - db.env
    depends_on:
      - db
      - redis

  web:
    build: ./web
    restart: always
    ports:
# this port is reverse proxied by a caddy webserver
      - 0.0.0.0:11080:80
    volumes:
      - nextcloud:/var/www/html:ro
    depends_on:
      - app

  cron:
    image: nextcloud:fpm-alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html
    entrypoint: /cron.sh
    depends_on:
      - db
      - redis

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    ports:
      - 8003:80
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=db
    depends_on:
      - db

volumes:
  db:
  nextcloud:

[dkebler]

Of note NC is able to show a thumb of the file in the "details" pane so it's not like RD can't open the file it's just the url issue mentioned above.

[mvvvmd]

I'm running into this same issue with Collabora in Docker and Apache. I updated the docker image and proxy settings, in the Nextcloud Office settings it says "the Collabora Online server is reachable". However office files have webdav links now and cannot be opened.

When I configure the demo server it does work, the links have a openfile link and they open.

[markginter31]

I've run into a similar issue - and have found if I go to settings and choose "Use your own server" and save it with the auto-filled in info then it changes itself back to "Use the built-in" option and starts to work. It will then work until I need to reboot the server and then I need to redo those steps.
**Update - for me it appears to have been a timezone issue. I set the correct timezone on my server, rebooted, and now everything works without having to do the things I mentioned above.

[dkebler]

@mvvvmd I confirm it works fine using the demo server but this issue remains using the built in server. @markginter31 my issue is not whether the built in server can be enabled (it can) but rather like @mvvvmd the links are webdav (thus unknown and they download) rather than launching collabra built it. (also my server has correct timezone and time).

BTW I have spun up a nextcloud pi docker instance and it works there. I suspect it might be something related to my nginix proxy.

[mvvvmd]

@markginter31 I've fixed the timezone, no change, the php timezone was already correct just the system was not.

@dkebler I've installed the Built-in server, this works, own server option only gives the webdav links still. I triple checked the apache proxy config, docker, logs and /hosting/capabilities works in the browser.

If this is not a bug in the app it should get error checking/logging imo giving admins a indication where there might be a issue.

[gerazo]

This problem has been chased for months now here and also in richdocumentscode repo. People seem to solve this by changing some settings here and there, so they get satisfied (like me in #2027 ). However, the satisfaction keeps only until the next upgrade.

I am recently being forced to restart Collabora CODE every night on the server, because it has memory leak in it ( CollaboraOnline/richdocumentscode#176 ), and every morning, some users, but really just some report this issue. They get the download dialog instead of opening the document. This happens without any upgrade done, just because the webserver was restarted. What solves this is cleaning the browser cache from the last 24 hours. At least, it solved the problem on multiple Chromium-based browsers.

Isn't it some kind of caching issue where richdocuments app looks for and older instance of the richdocumentscode server?

[dkebler]

To add to the discussion I spun up nc23 all in one which includes a collabra docker server. That seems to work fine. So separate server or demo server ,also technically a separate server, fine just built in one seems to have the issue.

[dodedodo]

I've had a similar issue multiple times. I run nextcloud in docker with a separate collabora/code container (not the built-in nextcloud app)

If this happens to me, usually a restart of my whole nextcloud stack/compose is enough to fix it. My theory until now is that the order in which containers come online varies slightly each time I restart the stack. I have not truly tested this so this theory might be complete bullshit.

[joshtrichards]

While there sound like there may be multiple matters covered in this Issue, I'll note that using Alpine based Docker images with the Collabora Online - Built-in CODE Server doesn't meet the system requirements due to musl (glibc is required for Collabora Online): https://github.com/CollaboraOnline/richdocumentscode#system-requirements

[joshtrichards]

app:
image: nextcloud:fpm-alpine

Since the original reporter was using an Alpine based image with richdocumentscode which isn't supported because the lack of glibc creates problems, I'm going to close this.

Though there should have been a visible warning, admittedly: #1026

A lot of things have changed in the mean time as well. If anyone else has a similar matter, please create a dedicated issue with your details to be evaluated directly.

@dkebler Since this is your Issue, if you're still experiencing this let me know and I'll reopen.