opencloud-eu
Optimization: Avoid access via external interface for simple uploads
Is your feature request related to a problem? Please describe.
Hi, thank you for this project. I am enjoying using this. However, I've encountered problems when I am running opencloud completely offline insde an internal docker network.
When trying to upload a file, I see this log:
{
"level": "error",
"service": "ocdav",
"name": "eu.opencloud.web.ocdav",
"path": "/",
"filename": "filename",
"error": "Patch https://opencloud.example.com/data/***: dial tcp: lookup opencloud.example.com on 127.0.0.11:53: server misbehaving",
"time": "2025-04-19T23:52:00+02:00",
"line": "github.com/opencloud-eu/reva/[email protected]/internal/http/services/owncloud/ocdav/tus.go:299",
"message": "error doing PATCH request to data gateway"
}
where opencloud.example.com is my opencloud address. It seems that the ocdav service are trying to call the opencloud service by its public address rather than an internal address like http://0.0.0.0:9200/data.
Describe the solution you'd like
I would like to know if there is any environment variable that needs to be set so ocdav can use the correct internal url. We have GATEWAY_GRPC_ADDR that has some similar effect for reva so I am hoping we have an environment variable for this too. Thank you very much
I am not sure what you mean with "completely offline" here. Maybe you want to elaborate on that a bit? Probably it's just a misunderstand in what you want to achieve.
OpenCloud needs to be able to resolve it's own external hostname to an IP address. AFAIK there is currently no way around that.
Hi I want to put opencloud inside an internal docker network (no outbound to the internet) and have a reverse proxy routes inbound traffic to it.
OpenCloud needs to be able to resolve it's own external hostname to an IP address. AFAIK there is currently no way around that.
Could you elaborate more about it ? Because it seems that opencloud is now doing something like opencloud service -> internet -> another opencloud service. Could we just skip the internet part and do opencloud service -> another opencloud service by some internal network
Furthermore, if I add an alias like opencloud.example.com to my reverse proxy, so the traffic will flow like opencloud service -> reverse proxy (internal) -> another opencloud service and there is no need for a internet connection. So I wonder if we could configure it to talk to each other directly
Furthermore, if I add an alias like
opencloud.example.comto my reverse proxy, so the traffic will flow likeopencloud service -> reverse proxy (internal) -> another opencloud serviceand there is no need for a internet connection. So I wonder if we could configure it to talk to each other directly
Does it work for you if you add that alias? Because that was what I was about to suggest.
Currently, for the upload case, we don't have another way I fear. The uploads happen via the TUS protocol. TUS generates a temporary upload URL where the clients (e.g. the web interface or the desktop client) upload the data in chunks. In some cases the initial request for creating an upload can already contain the first chunk of data (which is what happens in your case). In that case opencloud itself act as the uploading client for the first chunk. But it needs to use the same URL (as generated by the TUS protocol) for uploading that chunk. So that URL needs to be resolvable internally and externally.
There is probably some room for optimization here so that the internal upload would in a somewhat more clever way (e.g. circumvention the need to go via the reverse proxy again). But I think that would require some bigger changes. So don't hold you breath 😄.
Until then I think you need to setup the docker dns in a way to resolve the external hostname to the IP of you reverse proxy. Either by setting an alias or via --add-host
Thank you for your detail explaination. It seems to work if I add that alias and nothing is broken so far. I think we can leave the issue open until the optimization is implemented.
@StinkyTACO my configuration is quite similar to the docker-compose example except that the reverse proxy (traefik) container has a network alias https://stackoverflow.com/questions/33695702/how-can-i-add-hostnames-to-a-container-on-the-same-docker-network which points to opencloud.example.com
Currently, for the upload case, we don't have another way I fear. The uploads happen via the TUS protocol. TUS generates a temporary upload URL where the clients (e.g. the web interface or the desktop client) upload the data in chunks. In some cases the initial request for creating an upload can already contain the first chunk of data (which is what happens in your case). In that case opencloud itself act as the uploading client for the first chunk. But it needs to use the same URL (as generated by the TUS protocol) for uploading that chunk. So that URL needs to be resolvable internally and externally.
There is probably some room for optimization here so that the internal upload would in a somewhat more clever way (e.g. circumvention the need to go via the reverse proxy again). But I think that would require some bigger changes. So don't hold you breath 😄.
Why can't ocdav just replace the external OC_URL with an internal URL when it detects it? Being able to opt-in by setting a variable would probably be fine. I found it really odd that I had to create a firewall rule accepting connections from opencloud to its own reverse proxy.
