Loading documents always show "The file content does not match the file extension"

Hello,

I’ve set up an OnlyOffice server as a shared service in an environment where multiple frontend (FE) and backend (BE) installations are running on a Docker host. Inside my web-application the OnlyOffice frontend loads successfully, but I encounter the following error when trying to open a file:
“An error has occurred while opening the file. The file content does not match the file extension.”
The file itself can be downloaded in the browser directly using our file download service (auth_request in location of file server is temporarly deactivated for testing).
Additionally, running docker logs -f for the OnlyOffice container doesn’t show any logs while attempting to open the file as well as the log files themselfes do not have got any entries.

Here is how the OnlyOffice component is being called from the frontend:

<DocumentEditor
  id="onlyoffice-editor"
  documentServerUrl={`${process.env.REACT_APP_URL}api/office`}
  config={{
    document: {
      fileType: 'docx', // temporarly hard-coded for testing purpose
      key: `file-${new Date().getTime()}`,
      title: 'Test',
      url: fileUrl, // pointing to our file download service
    },
    documentType: 'word', // temporarly hard-coded for testing purpose
    editorConfig: {
      mode: 'view',
      ...
    },
  }}
  ...
/>

Here is the docker-compose.yml configuration for the up and running container:

services:
  onlyoffice:
    image: onlyoffice/documentserver:latest
    container_name: development_office
    restart: always
    ports:
      - "3019:80"
    stdin_open: true
    environment:
      - JWT_ENABLED=false
      - JWT_SECRET=test
      - JWT_HEADER=Authorization
      - ENABLE_TLS=false
    volumes:
      - ./office/logs/:/var/log/onlyoffice
      - ./office/data/:/var/www/onlyoffice/Data
    networks:
      - "application/network:development"

networks:
  "application/network:development":
    external: true

Additionally, here is the relevant NGINX location configuration for OnlyOffice on the Docker host:

location /api/office/ {
    # auth_request /backend/public/services/authenticate;
    # error_page 401 = /error401;
    proxy_pass http://localhost:3019/;  # Backend for ONLYOFFICE
    proxy_http_version 1.1;

    # WebSocket Headers
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # Forwarding Headers
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # Buffering Settings for WebSocket
    proxy_cache_bypass $http_upgrade;
    proxy_set_header X-Accel-Buffering 'no';
    proxy_buffering off;
    chunked_transfer_encoding off;

    # Rewrite for Compatibility
    rewrite ^/api/office/(.*) /$1 break;
  }

Has anyone encountered this issue before or can offer guidance on how to resolve it? I’ve already checked relevant posts and the guides for setting things up containered. Any insights or suggestions would be greatly appreciated!

Thanks in advance.
Marc

Hello @graph-designer,
Please provide the original file with which the issue is reproduced

Hello Dmitrii,

it can be reproduced with various files. Here’s the last one I’ve tried: test (13.1 KB)

Kind regards,
Marc

Please provide Document Server logs as file (/var/log/onlyoffice/documentserver - inside the container) together with the full Editor’s initialization config (as file)

I really would like to have some logs. But all of them are 0 byte long for todays test. Also looking at the direct output of the container via docker logs -f doesn’t show anything.

root@736d5e73d217:/var/log/onlyoffice/documentserver# ls -l
total 24
drwxr-xr-x 2 ds       ds 4096 Jan 17 06:37 converter
drwxr-xr-x 2 ds       ds 4096 Jan 17 06:37 docservice
drwxr-xr-x 2 ds       ds 4096 Jan  9 10:18 metrics
-rwxr-xr-x 1 www-data ds    0 Jan 17 06:37 nginx.error.log
...
root@736d5e73d217:/var/log/onlyoffice/documentserver# ls -l converter/
total 44
-rwxr-xr-x 1 ds ds     0 Jan  9 10:18 err.log
-rwxr-xr-x 1 ds ds     0 Jan 17 06:37 out.log
...
root@736d5e73d217:/var/log/onlyoffice/documentserver# ls -l docservice/
total 36
-rwxr-xr-x 1 ds ds    0 Jan  9 10:18 err.log
-rwxr-xr-x 1 ds ds    0 Jan 17 06:37 out.log
...
root@736d5e73d217:/var/log/onlyoffice/documentserver# ls -l metrics/
total 0

And the editor is initialized via the docker-compose config I’ve already sent. There’s nothing additionally configured. Please give me a hint if you need a specific conf file.

Hello @graph-designer,
Sorry for the delayed response, please provide the screen recording of the issue reproduction with Browser’s DevTools Console and Network tabs opened (F12 for Chrome/Firefox)
Also, earlier you provided only a section of your Editor’s initialization config, please provide the whole config as file

Hello @DmitriiV ,
attached is a screen recording showing the issue. Additionally, the whole config:

  config={{
            document: {
              fileType: 'docx', // temporarly hard-coded for testing purpose
              key: `file-${new Date().getTime()}`,
              title: `Test Document - ${fileType.toUpperCase()}`,
              url: fileUrl, // pointing to our file download service
            },
            documentType: 'word', // temporarly hard-coded for testing purpose
            editorConfig: {
              // callbackUrl: `${window.location.origin}/callback`, 
              mode: 'view', 
              customization: {
                forcesave: false, 
                help: false, 
                hideNotes: true, 
                hideRightMenu: true, 
                hideRulers: true, 
                integrationMode: 'embed', 
                autosave: false, 
                comments: false, 
                compatibleFeatures: false, 
                macros: false, 
                mentionShare: false,
                plugins: false, 
                submitForm: false,
                toolbarHideFileName: false,
                zoom: 100, 
                compactToolbar: true, 
                compactHeader: true, 
                chat: false, 
                toolbarNoTabs: true, 
                logo: {   
                  image: null,
                  imageDark: null,
                  url: null,
                },
                uiTheme: 'default-light',
                macrosMode: 'disable',
                features: {
                  
                  roles: true,
                  spellcheck: {
                    mode: true,
                    change: true,
                  },
                  tabBackground: {
                    mode: 'toolbar',
                    change: true,
                  },
                  tabStyle: {
                    mode: 'fill',
                    change: true,
                  },
                }
              },              
            },
  
          }}

Kind regards,
Fabian

Could you maybe, please, provide the link to your system and a way to log in, so we could perform tests there ourselves? (you can send this in PM)

We’ve checked the issue reproduction on the side of your application. Please check if the issue is also reproduced on the Example Page (documentserver_url/example)
Also, please give an example of an actual generated link leading to the document in the storage (by which Document Server downloads the file)
Please try manually downloading some file from such a link and opening it on the Example afterwards.
And, finally, please try providing an absolute link to some particular file as url parameter (instead of a variable) and check if in that case the file opens

I am running into the same error just right now.

For me it happened when I moved the document server proxying from root (on a sub-domain) to sub-routes on it, just like in the nginx config that @graph-designer has.

Further testing on our side has shown that the issue was caused by the Nginx config. Using a subdomain successfully resolved the problem. Thank you for your support.

Glad to know that the issue has been resolved, thank you for sharing

@jakob It is highly likely that the cause for the issue is the same as in the case discussed above. It must be connected with proxying configuration