Error when trying to connect (Error occurred in the document service: Error while downloading the document file to be converted.) (version 7.2.1.34)

Hello @mx5gr
Thank you for the logs. I’ve found a lot of ‘404’ errors entries when Document server tried downloading a file from http://owncloud_server:8080 address. It seems as DNS\proxy issue. Have you compared your traefik config files with our samples? Using ONLYOFFICE Docs behind the proxy - ONLYOFFICE
Also, please try to remove internal addresses from the connector page app (http://owncloud_server:8080 and http://onlyoffice_documentserver). Will the situation change?

The file that is indicated multiple times within the logs is the same one.

When I tried to download it manually via cURL from within the containers, I got a 403 message (normal, I thought, because I did not pass a token).

I tried the same URL from my browser, while I was already logged in to owncloud. In this situation, the file downloaded perfectly… that means (to my mind) that the URL is not malformed but it might have something to do with another issue.

Regarding the Traefik settings, the ones you have released as settings for various scenarios refer to Traefik v1 not v2. The ones we are using, however, are fully compatible with the released ones.

I removed the internal URLs, as you mention, to no avail however…

It seems that the issue has to do with files on external storage, despite being available through webdav and the web interface.

For a local file, we get in owncloud logs:

172.18.0.7 [Traefik Proxy] - - [19/Sep/2023:08:06:20 +0000] "GET /ocs/v2.php/apps/onlyoffice/api/v1/config/9741?filePath=%2FDocument.docx&inframe=true HTTP/1.1" 200 3729 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0"

172.22.0.5 [Document Server] - - [19/Sep/2023:08:06:21 +0000] "POST /apps/onlyoffice/track?doc=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJBZG1pbmlzdHJhdG9yIiwib3duZXJJZCI6IkFkbWluaXN0cmF0b3IiLCJmaWxlSWQiOjk3NDEsImZpbGVQYXRoIjoiL0RvY3VtZW50LmRvY3giLCJzaGFyZVRva2VuIjpudWxsLCJhY3Rpb24iOiJ0cmFjayJ9.pMPC6yMHgwCHHnFOKj1yYy1FtBPstPjWepfBywJbjow HTTP/1.1" 200 1042 "-" "Node.js/6.13"

172.22.0.5 [Document Server] - - [19/Sep/2023:08:06:21 +0000] "GET /apps/onlyoffice/download?doc=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhY3Rpb24iOiJkb3dubG9hZCIsImZpbGVJZCI6OTc0MSwidXNlcklkIjoiQWRtaW5pc3RyYXRvciJ9.FqDELL0m19jA8mmQ-DsnZFPkQQeiI_L3eLCUa7zgz_o HTTP/1.1" 200 8064 "-" "Node.js/6.13"

172.18.0.7 [Traefik Proxy] - - [19/Sep/2023:08:06:19 +0000] "GET /remote.php/dav/files/Administrator/Document.docx?c=647ba1930955271c7c6c890a5e2b093b&x=32&y=32&forceIcon=0&preview=1 HTTP/1.1" 200 1003 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0"

… and onlyoffice opens fine!

For an external document now, we get:

172.22.0.5 - - [19/Sep/2023:08:43:00 +0000] "GET /apps/onlyoffice/download?doc=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhY3Rpb24iOiJkb3dubG9hZCIsImZpbGVJZCI6OTc3NywidXNlcklkIjoiQWRtaW5pc3RyYXRvciJ9.z_yTXewGqq6IlEpyttt_2ETNMjXaMBlUtI0j1kaUDb8 HTTP/1.1" 404 1063 "-" "Node.js/6.13"

172.22.0.5 - - [19/Sep/2023:08:43:01 +0000] "GET /apps/onlyoffice/download?doc=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhY3Rpb24iOiJkb3dubG9hZCIsImZpbGVJZCI6OTc3NywidXNlcklkIjoiQWRtaW5pc3RyYXRvciJ9.z_yTXewGqq6IlEpyttt_2ETNMjXaMBlUtI0j1kaUDb8 HTTP/1.1" 404 1061 "-" "Node.js/6.13"

… and we get the Download error within onlyoffice, probably because owncloud refused to serve the request.

IF now the same URL that got the 404 above is accessed through a browser from a client that is already logged into owncloud (where we are trying to edit the document, for example), the document is served perfectly by owncloud and it is downloaded locally.

Hello @mx5gr
Thank you for the provided information.
Do I understand the issue scenario right? Are files located on the external storage (what kind of external storage have you connected to ownCloud?) not available for opening in the editor with 404 error entry?

You are correct! This is the scenario…

Hello @mx5gr

Please specify the earlier asked information.

Additionally, please run a test: since the issue reproduces only (correct me if I’m wrong) with files located in external storage but the link can be accessed via browser from the client, I’d also ask you to check the link but from the server where Document Server is installed with wget or curl, for instance. What error is returned that way, 403 or 404?

Hello,

The external storage is a Windows share (CIFS).

As for the error, I get 403 from the server (probably because I haven’t provided a token within the request?)

I think your storage requires authentication to access the document. The terminal does not provide any credentials as such, as a result 403.

Do you use localhost in the link?

When the URL is fed to the browser that is already logged into owncloud, the document is downloaded flawlessly. When it is accessed via the onlydocuments server, then I get 404 in the logs and 403 when accessed directly through cURL.

If additional authentication was required @ the external storage level, then it wouldn’t popup during the browser access? Isn’t the JWT token playing its part here for auth purposes?

Are both ownCloud and Document Server installed on the same server?


I’m not quite sure how your external storage is configured. Most certainly, it passes authentication automatically from ownCloud, thus when accessing via direct link it passes auth from ownCloud side. JWT here protects communication between Document Server and ownCloud and has nothing to do with your external storage.

For sure, that’s what happens. However, it is not common for CIFS/Windows shares to be completely unprotected, without any user-level permissioning.

This happens in both owncloud CIFS scenarios, i.e. either when the credentials, on a share level, are provided per session or when the share is available to all owncloud users, with centrally defined username & password for share access.

Basically, from what I can interpret from your answer (if I’m not mistaken, that is), if you have an external share with any kind of password protection (either session-based or centrally defined), then onlydocuments cannot access it. However, for locally-stored folders and files (which are also protected on a user level), the content can be accessed.

I would expect, however, that any files that are visible to the server within Owncloud, are available to onlydocuments for preview/editing.

Please let us know what storage do you use exactly, its version and how it is connected to ownCloud. If it has particular configuration, please describe it in details.

Hi there,

I have exactly same problem but only with version 7.5.

I tried everything in this thread with no success…

  • Nextcloud and OnlyOffice on the same server behing an haproxy (with ssl offloading).
  • No Docker normal install.
  • Onlyoffice listening internaly on http.

Haproxy configuration checked with Using ONLYOFFICE Docs behind the proxy - ONLYOFFICE ==> no problem (it’s being working with all other onlyoffice version since 3 years…)

config.php

'onlyoffice' =>
  array (
    'verify_peer_off' => 'true',
    'jwt_header' => 'AuthorizationJwt',
    'jwt_secret' => '<secret_secret>',
  ),

local.json

{
  "services": {
    "CoAuthoring": {
      "sql": {
        "type": "postgres",
        "dbHost": "localhost",
        "dbPort": "5432",
        "dbName": "onlyoffice",
        "dbUser": "onlyoffice",
        "dbPass": "<secret_pass>"
      },
      "token": {
        "enable": {
          "request": {
            "inbox": true,
            "outbox": true
          },
          "browser": true
        },
        "inbox": {
          "header": "AuthorizationJwt",
          "inBody": false
        },
        "outbox": {
          "header": "AuthorizationJwt",
          "inBody": false
        }
      },
      "secret": {
        "inbox": {
          "string": "<secret_secret>"
        },
        "outbox": {
          "string": "<secret_secret>"
        },
        "session": {
          "string": "<secret_secret>"
        }
      }
    }
  },
  "rabbitmq": {
    "url": "amqp://guest:guest@localhost"
  },
  "storage": {
    "fs": {
      "secretString": "<other_secret>"
    }
  }
}

Error 403 in the logs…

If i downgrade to 7.4 everything works normaly again…

Any other information will be appreciated !

Regards

Hello @crocobc

Please check logs of Nextcloud too. I’d ask you to gather all logs of Nextcloud and Document Server after reproducing the issue into a single archive and share it for analysis.

Additionally, please check if editing works in integrated test example. Simply navigate to Document Server address, enable example according to the instruction on Welcome Page, once enabled press GO TO TEST EXAMPLE button and upload/create a document to check.


If possible please create separate thread where provide detailed information about your environment as well as the logs.

Hi there,

Thank you for reply.

It’s working on local address with test example.

Logs from Documentserver:

[2023-11-03T13:12:03.113] [ERROR] [localhost] [192.168.10.200new.docx11685683144951] [uid-1] nodeJS - error downloadFile:url=http://192.168.10.104:8181/example/download?fileName=new.docx&useraddress=192.168.10.200;attempt=3;code:null;connect:null Error: Error response: statusCode:403; headers:{"server":"nginx","date":"Fri, 03 Nov 2023 09:12:03 GMT","content-type":"text/plain; charset=utf-8","content-length":"9","connection":"close","access-control-allow-origin":"*","etag":"W/\"9-PatfYBLj4Um1qTm5zrukoLhNyPU\""};

For testing purpose i mounted a Nextcloud AIO in another VM ==> Exactly the same error…so i think it’s more related to my configuration (reverse Proxy ?)

I have no time to search this or create another thread (it’s only related to THIS version 7.15 for me), i just downgrade and i will wait ^^

Regards

EDIT

After some search i solved it. :slight_smile:

After some digging, i undetsood that problem was not in onlyoffice or Nextlcoud.
I did cross tests with another similar configuration and found THE difference that made the trick for me.

My Haproxy Frontend configuration was having this directive:

http-request deny if { hdr_cnt(user-agent) eq 0 }

This directive returns an HTTP 403 Forbidden error when the user-agent is empty…

Removing it solve the problem.

It may help another people we never know…

We are glad that the situation is solved. Please feel free to contact us if you face any issues.

Error when trying to connect (Error occurred in the document service: Error while downloading the document file to be converted.) (version 7.5.1.23)

{
“services”: {
“CoAuthoring”: {
“sql”: {
“type”: “postgres”,
“dbHost”: “localhost”,
“dbPort”: “5432”,
“dbName”: “onlyoffice”,
“dbUser”: “onlyoffice”,
“dbPass”: “onlyoffice”
},
“token”: {
“enable”: {
“request”: {
“inbox”: true,
“outbox”: true
},
“browser”: true
},
“inbox”: {
“header”: “AuthorizationJwt”,
“inBody”: false
},
“outbox”: {
“header”: “AuthorizationJwt”,
“inBody”: false
},
“secret”: {
“inbox”: {
“string”: “mz8n3ntB3sTd15XgTQcHJaWa5S2Lg091”
},
“outbox”: {
“string”: “mz8n3ntB3sTd15XgTQcHJaWa5S2Lg091”
},
“session”: {
“string”: “mz8n3ntB3sTd15XgTQcHJaWa5S2Lg091”
}
}
}
}
},
“rabbitmq”: {
“url”: “amqp://guest:guest@localhost”
},
“storage”: {
“fs”: {
“secretString”: “hZsYhujxrkXv52C26LEf”
}
}
}

),
‘onlyoffice’ =>
array (
‘verify_peer_off’ => ‘true’,
“jwt_secret” => “mz8n3ntB3sTd15XgTQcHJaWa5S2Lg091”,
“jwt_header” => “AuthorizationJwt”
),
);

Hello @ahmad
As far as I understand, you created a separate thread for the situation that you faced: Community document Server
Please do not create multiple requests on the same issue.