Hi!
I am new to Seafile. In essence, I am looking for a better/leaner alternative to Nextcloud. So far I have been able to successfully install Seafile 12 in a Docker environment that runs the Cosmos Cloud container management environment on top of Debian Bookworm. Now I am trying to get Seadoc to work also. I am trying to follow the official documentation for Seafile 12, but as I am unable to use Caddy for reverse proxying in my enviroment, I have to do some guessing when it comes to that bit. Also, port 80 is used for other services in my environment, so the seadoc-server cannot use that port. Currently I am giving it port 8083. I then instruct Cosmos to proxy the name sdoc.puke.se to http://:8083.
It appears that I can access this address, because if I point my web-browser to it, I get {"error_msg":"You don't have permission to access."}
However, if I click on “foo.sdoc” in the file explorer view of Seafile, I get
Load doc content error
in red.
So, I don’t understand where to go from here. Can someone give some tips?
Thanks for your suggestions!
Unfortunately I still cannot get it to work. Here is what I tried:
Attempt 1:
In .env I changed SEADOC_SERVER_URL from https://sdoc.puke.se/sdoc-server to just https://sdoc.puke.se
Result: Same problem as before.
Attempt 2:
I changed back SEADOC_SERVER_URL to https://sdoc.puke.se/sdoc-server
and instead changed the proxy server to point https://sdoc.puke.se/sdoc-server 192.168.1.22:8083 (before it was pointing https://sdoc.puke.se without the trailing /sdoc-server).
Result: Same as before.
Looking at “plus-dot-seafile-dot-com”, it looks as if the sdoc-server is accessed through the sfile URL, just adding an extension to it. So, does this mean that I don’t need a separate sub-domain for the sdoc server?
If I point my browser to the internal IP-address and port-number of the sdoc-server, I get the same result as when pointing it to the sdoc-pathsuffix of the plus-dot-sfil-dot-com server. This should mean that the sdoc-server is running, and that my problems are entirely related to what should be in the .env-file and how the proxy-rules should be set up.
What I think I need to understand to get this to work, is how the proxy rules are supposed to be set up, especially since I cannot use port 80 for the sdoc-server and I cannot use Caddy as the reverse proxy.
If someone has rules for instance Nginx Proxy Manager, I could work with those to figure it out.
Or - if someone can explain in detail how the sfile-server talks to the sdoc-server, then maybe I can reverse-engineer what I need to do.
I have now spent an entire, long, day trying to get either Sdoc, OnlyOffice or Collabora to work. And I have failed with every three of them. In the process, I get a lot to learn from how Seafile works, but apparently not enough to understand what I am doing wrong.
Collabora ought to be the easiest to get working, as it shares the same network as Seafile inside the same container stack. And inside the Seafile container, I have no problem reaching to the collabora container instance. However, I cant get things to work from the outside. So when I click on a file with a .docx extension, and expects to get Libreoffice up and running, nothing happens (it times out after a while).
If you don’t have a lot of experience in reverse proxy, I suggest you get a new virtual machine with a clean environment and use Caddy as reverse proxy and standard port. By strictly following our document, it will be much easy to set Seafile up.
Thanks for your suggestion, however that will unfortunately not solve my problem. As I run several services in my home network, and I only have one external IP-adress, there can only be one reverse proxy to handle all services (unless I am completely wrong). And in my case that would be the reverse proxy built into Cosmos cloud.
So if it is impossible to get information about how Seafile and the document manager (Seadoc, Onlyoffice or Collabora) talks to each other, then I suppose I am left with two options:
Make do without a document management system. The Markdown editor of Seafile is quite powerful in its own right and can be useful for many purposes, and external editors (MS Office for instance) can take care of editing office documents. That would mean that colloborative editing is out of scope of course.
Find a different file management solution. I already have Nextcloud up and running, but it is slow and breaks easily with updates, so I will not use that. Perhaps Owncloud or Filestash or something else will work. I will investigate.
I don’t know anything about cosmos cloud or what its reverse proxy is like, but I have an example from getting seadoc to work on my test setup with nginx as the reverse proxy. I decided not to use seadoc, so it didn’t get much testing, but it did work.
Seadoc used the same domain name as seafile. I just had to configure nginx to forward anything going to https://seafile-test.mydomain.net/sdoc-server and https://seafile-test.mydomain.net/socket.io to the sea-doc server instead of the seafile server. I used port 80 for this connection, but I don’t see any reason it couldn’t be any other convenient port. If you put this ports section in your seadoc.yml it will have docker listen on 8888, and forward to port 80 inside the container.
ports:
- "8888:80"
And my nginx config for seadoc looked like:
location /sdoc-server {
proxy_pass http://10.20.30.40:8888;
include /etc/nginx/snippets/proxy.conf;
client_max_body_size 0;
# supposed to fix large file uploads with web interface
proxy_request_buffering off;
access_log /var/log/nginx/seafhttp.access.log;
error_log /var/log/nginx/seafhttp.error.log;
}
# another part of seadoc.
location /socket.io {
proxy_pass http://10.20.30.40:8888;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_redirect off;
proxy_buffers 8 32k;
proxy_buffer_size 64k;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
access_log /var/log/nginx/seafhttp.access.log;
error_log /var/log/nginx/seafhttp.error.log;
}
Since this was just a test deploy and I didn’t move on to deploying to production, I can’t say that any of this configuration is optimal, but it did work.
I use Collabora, and that setup is a little different. For collabora I have a separate subdomain for it. So anything going to collab.mydomain.net gets forwarded to the collabora server. Then in
seahub_settings.py on seafile server I have:
OFFICE_WEB_APP_BASE_URL = ‘https://collab.mydomain.net/hosting/discovery’
For a while with both I was getting errors that I think were a lot like what you described. I eventually tracked it down to a configuration on my router/firewall that meant that seafile, sea-doc, and collabora couldn’t use the public URLs to talk to each other. If I ran “curl https://collab.mydomain.net/” from the seafile server, I would get an error about a time out or the connection being refused or something, but it would work fine from my computer on another network. The router wouldn’t let connections coming from the internal networks talk to the public IP like they were coming in from the internet. Once that was fixed, it was pretty much like the documentation described (though converted for my reverse proxy since I don’t use cady).
Great! That was indeed very useful information.
I experimented with trying to get Onlyoffice to work instead by setting up onlyoffice-server on its own in a separate Linux container (LXC). By using this approach, Onlyoffice gets its own IP adress. Currently I am at a point where I can view an office-document that I click on in the Seafile user interface as long as I only use the internal IP-adress of the Seafile server. However, I can’t edit it (there is no user interface for that for some reason). I will experiment further, letting the Onlyoffice server work on port 80 and give it its own external file-name in the proxy, then edit the python configuration file in Seafile-hub accordingly and see what happens.
So it feels like I am “almost there”, but can’t get past the last (?) hurdle.
Now I have Onlyoffice running in a separate virtual machine (or LXC to be precise), so it has its own IP adress and I get the welcome page.
I have now also set up a proxy rule so that I can reach this Onlyoffice server from outside.
I can run Seafile and can upload and download files as well as create markdown files in the browser.
I have changed things in the seahub-settings.py so that the Onlyoffice server address is now my external subdomain.
When clicking a .docx file using Chrome, I get an error message saying that the server refused to connect.
If I do the same thing i Firefox, I am told that the browser stopped the connection because it refuses to open another site in an iframe.
So what should my next step be?
I don’t really know, but given that message about refusing to open in an iframe, I suspect that your reverse proxy might be setting a header to tell the browser that the page can’t be shown in an iframe, like “X-Frame-Options: DENY” for example.
I would suggest that you try pressing F12 to open the browser’s debug frame, and look in the network section. You should see there all the headers that the server sent to the browser. Look through them (and google them) to see if one is preventing the page from loading in an iframe.
When defining the reference to the Onlyoffice-server in the seahub_settings.py configuration file as an externally reachable url, I get a blank page with just the document name on the top. I press F12 to get the debugger and to my untrained eye, everything looks normal - I can read the javascript-code. However on the “console” tab, I see the following:
“Uncaught ReferenceError: DocsAPI is not defined
at Loremipsum.docx:343:19”
So, it appears that getting the script from an external (proxied) url does not work.
Changing the url to the Onlyoffice server in seahub_settings.py to use the http:///… instead gives me the following error in the web-console instead:
“Loremipsum.docx:1 Mixed Content: The page at ‘Log In - Pukes Drive’ was loaded over HTTPS, but requested an insecure script ‘http://192.168.1.68/apps/api/documents/api.js’. This request has been blocked; the content must be served over HTTPS.”
So, it seems that when using https:// the scripts are not found, and when using http://<ip.of-my-onlyoffice-server> the scripts are found, but not accepted due to insecured server.
Where do I go from here?
EDIT: Looking at the web-developer tools in Firefox, I get a little more info. When deploying the secure server URL for Onlyoffice, I get the following error in the console:
Resursen från “https://oo.puke.se/apps/api/documents/api.js” blockerades på grund av MIME-typ (“text/html”) obalans (X-Content-Type-Options: nosniff).
Loremipsum.docx
Laddning misslyckades för <script> med källan “https://oo.puke.se/apps/api/documents/api.js”. Loremipsum.docx:218:83
Uncaught ReferenceError: DocsAPI is not defined
<anonymous> https://drive.puke.se/lib/4eb38c1c-91bc-4724-9400-4c64218b434e/file/Loremipsum.docx:343
Let me translate for those not familiar with Swedish:
"The resource from (https …) was blocked due to a MIME-type (“text/html”) discrepency. (X-Content-Type-Options: nosniff).
Loading did not succeed for with the source (https…) Loremipsum.docx:218:83
OK, so I made another attempt, using the provided example as a base where both Seafile and Onlyoffice are deployed using Docker and share the same seafile-net network. (As before, I can’t use Caddy).
From inside the seafile container, I can reach the seafile-onlyoffice container and get the javascript-code like so:
So this is what I initially set the ONLYOFFICE_APIJS_URL variable to in seahub-config.py.
However pointing the browser to the external URL pointing at my Seafile instance, then selecting my Catalog and then a file with a docx-extension gives me a blank page. Inspecting the web-console I can see that the web-browser refuses to load the code from the onlyoffice container, as it is not secure (https) which the seafile container is.(Mixed-content error message)
Next attempt is to make the onlyoffice-container secure. So I install a self-signed certificate.
Now I can access it from the seafile-container securely, but only if I use the flag --no-check-certificate flag, as otherwise the self-signed certificate is not accepted. This is easy when I use wget to try out the connection within the seafile-container, but how can I tell it to accept a self-signed certificate for the normal operation of seafile? I have not found a flag or variable to accomplish this. Can you help me?
OK, so I got some help from ChatGPT but it did not bring me to a working solution. Also, I did yet another attempt with Collabora, also with help from ChatGPT. No joy. So I am giving up on this!
I am sorry. I got sick and haven’t been watching for a while. It sounds like you are pretty close, and are having a problem I faced, where the seafile server can’t talk to the onlyoffice server on the public address (going through the reverse proxy the same as a client machine would). If that is the case, you might only need to turn on the NAT Reflection or NAT hairpin setting on your router. This is the setting I was saying I changed to allow the seafile server to talk to the public address for onlyoffice.