Hi @faktori,
I pushed a new collabora/code docker image to docker hub, which has a fix for the āspecial characterā problem. The docker image did not have the locales in it, and lacale set to POSIX. However, in this case LibreOffice can handle only ASCII file names. The solution was to install all locales, and I set en_US.UTF-8 in the environment. Thanks for the bug report.
Best regards,
Andras Timar
Hi @timar,
Is there any chance to have ARM (aarch64) docker images? I guess many of us have those SoC as own/nextcloud server and it would be great to play with CODE.
Best
Hello Timar, thank you for your help on this topic
I have downloaded your last image on docker hub and I am using it.
However I am still having āconnectingā delay of almost 30 seconds for my documents.
I tried opening some files on remote and local folders with no differences on the delay.
I tested collabora with various formats, (doc(x), xls(x), ): again no differences
An near empty 9kB odt file still takes 30sec to open.
So Iām pretty confident it is not a lool performance issue
I also tried repatching the docker image (just in case of ā¦) but I didnāt get any improvement.
I there anybody still having a 20sec+ delay with the newest docker image ?
(My server is a dual core vps from OVH, itās āunder-usedā, so Iām quite confident this is not a local performance issue)
Regards, Aal.
many thanks @timar for this. itās working well 
hi @aalaesar i can confirm that the new docker image has this DNS issue resolved and iām no longer getting the additional 20 second delay when opening documents. i have performed tcpdump testing on the docker0 virtual interface and all requests are being handled correctly.
Thanks! For me the problem is solved now
For reference here is how fast it is for me now:
(It are two separate VPSāes, one with Collabora running in Docker + Apache proy and one with the Nextcloud installation)
@aalaesar are you sure you have stopped and started the docker container after pulling? More information here: Collabora online - Nextcloud (at the bottom of the page before the troubleshooting section)
Hello
thank you for your feed back,
So it confirms something is messed-up with my nextcloud instance. (upgraded to nextcloud 10, could be a causeā¦)
I did create a new container to test this image.
With further testing, I have weird symptoms on my instance (NC10) like :
Iāll make some more testing on my side, but Iām opened for any suggestion.
Regards,
Aal.
The section is under āAdditional settingsā
Oops 
I was looking to fast.
One mystery solved, Thanks !
I haventt found yet why I have a 30 sec delay on Edge and sort of ātimeoutā on the other browsers.
Hello.
I have tested 2 brand new instances of nextcloud:
1- v9.0.53 => opening Documents/example.odt : Everything works fine except closing & reopening the file immediately (āconnectingā delay, then āunexpected connexion errorā)
2- v10.0 => opening Documents/About.odt : āconnectingā delay, then āunexpected connexion errorā, no errors in logs.
Edge manages to work most of the time but with a āconnectingā delay of 30sec.
So I came to the conclusion that this topicās issue is solved 
but something is broken since nextcloud 10, at least on my side, but without obvious causes to be found in the logs, Iām clueless. Any hint ?
Regards
Iād like to invite people who want to try the libreoffice building, to follow this step (in deutch unfortunately):
Iāve builded LO using this guide on a Ubuntu Xenial VM, no 20 seconds delay, everything ok.
I tried the same thing on a debian jessie but here, no luck. I have 40 seconds delayā¦ I donāt know why but this is a different problemā¦ the vm performances are good (Iāve used the same VM of the ubuntu xenial) but the delay is enourmous.
Can anyone guide me through this issue? What can it be to create this long delay?
Thanks!
I solved my issue with the 2x delay!
As my previuos post, after compiling LO+loolwsd I was experiencing a ~40-44 seconds delay.
Iāve compiled LO+loolwsd on a VM located on my LAN, and then I moved the builded LO to my VPS that has only a public IP. Everything was working very good except this delay, it looked as a timeout somewhere so I decided to point out the DNS issues as per @wizdude post. Even if he were using the docker image and I was not, the theory of the DNS timeout made some sense to me, so, on my VPS I logged every packet going to private networks using this script:
#!/bin/bash
IPT=/sbin/iptables
$IPT -F OUTPUT
$IPT -A OUTPUT -d 10.0.0.0/8 -j LOG --log-prefix " LOG:"
$IPT -A OUTPUT -d 10.0.0.0/8 -j REJECT
$IPT -A OUTPUT -d 172.16.0.0/12 -j LOG --log-prefix " LOG:"
$IPT -A OUTPUT -d 172.16.0.0/12 -j REJECT
$IPT -A OUTPUT -d 192.168.0.0/16 -j LOG --log-prefix " LOG:"
$IPT -A OUTPUT -d 192.168.0.0/16 -j REJECT
No more delay and something really disappointing on the firewall logs:
Sep 6 19:39:30 oc kernel: [187734.187350] LOG:IN= OUT=eth0 SRC=188.x.x.x DST=192.168.10.2 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=65021 DF PROTO=UDP SPT=58650 DPT=53 LEN=41
Sep 6 19:39:30 oc kernel: [187734.187418] LOG:IN= OUT=eth0 SRC=188.x.x.x DST=192.168.10.3 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=26974 DF PROTO=UDP SPT=49437 DPT=53 LEN=41
Catch! 192.168.10.2 and 192.168.10.3 are my internal DNS listed on /etc/resolv.conf on the VM I used to build LO/loolwsd. The 2x delay is explained by my 2 dns servers: 20 seconds each = 40 secondsā¦
Anyone has any idea of the library/process that took the DNS from my building system? It may be happened during LO compiling or during the loolwsd compiling, Iād have to recompile loolwsd changing my system DNS and then look again, but not nowā¦ 
āupdate: The issue is on loolwsd only. I put a public DNS on my /etc/resolv.conf and I rebuilded loolwsd. Now the delay is gone, without any iptables workaround
Congratulations aventrax for finding the root of this problem.
Has it been reported to the libreoffice online project ?
Regards.
Not yet. Are you experiencing the same issue?
i discovered the root cause, remediated, reported it to libreoffice online and they have fixed it.
aventrax has a build fault with his own implementation. itās not even relevant to this thread which I started to discuss a fault/bug in the docker image.
i would kindly suggest that libreoffice building issues be relegated to a separate thread.
we are done here. the fault has been identified and fixed. end of thread.
cheers, wizdude.
Very rude and impolite.
Anyway, sorry for disturbing your thread, youāre the man.
@aalaesar, please congrats with him, otherwise his frustration will increase.
Ok, sorry I may have spoken to fast when i said it was the ārootā cause of the 20 sec delay caused by the DNS timeout.
You did find out this was a dns issue and proposed a quick and effective workaround.
Aventrax got a just little deeper. and may have found why the dns problem append in the container (this could be why the faulty resolv.conf changed between your tests)
This also need to be reported to github, doesnāt it ?
Iām just going to ignore the blaming and look at what I know about this issue:
So the issue was that the /opt/lool/systemplate/etc/resolv.conffile was created while building the Docker image on the computer of the creator of the Docker image. (this also indicates why the value inhere was changed with the first update of the Docker image). The issue was reported to the creator of the Docker image. This person then solved the issue for a lot of people. Iām quiet sure the /opt/lool/systemplate/etc/resolv.conffile was symlinked to the /etc/resolv.conf file, which is created by Docker. This can be checked by going into the container (docker exec -it ID /bin/bashand executingreadlink /opt/lool/systemplate/etc/resolv.confwhich will return/etc/resolv.conf. If I add theāip=208.67.222.222to the docker parameters, both the /etc/resolv.conf and the/opt/lool/systemplate/etc/resolv.conf` contains this nameserver.
Please make sure you are running the latest Docker image. Also if you are going to move files out of the Docker image to run on your own sever, or you compile it yourself, the symlink is lost.
iām sorry if you took offense to my comment, but this thread has become very polluted with all kinds of manual libreoffice build problems. this thread started because the docker image wasnāt working. this has now been fixed. i think it would be a fantastic idea if new threads were started to discuss any new problems to avoid confusion with others that might read this thread in relation to problem they might be experiencing with the docker image as well.
it makes for an improved and nicer support experience for users if each specific issue can be broken out and much quicker for people to search for as well.
+1
i think quite a few people who are reading this thread are striking the same core issue, but in a number of different ways. the build procedure for collabora is important and it appears several people, including the team who built the docker image, all made similar mistakes.
as far as the docker image is concerned, this has already been reported back and resolved. as far as local builds are concerned, this is probably all worked correctly and āby designā. i see this as a config issue rather than a code bug.
the reason this whole fiasco started in the first place is due to the fact that we are using collabora running in a docker container. this means (in simple terms) that you have an operating system with another (sub) operating system inside it and a protected subsystem inside that. the problem was hidden under multiple layers. the docker image was designed to be an easy āinstall and forgetā solution to avoid a complex build procedure.
with a standard build of libreoffice this becomes a much easier āpost configurationā step and probably wonāt affect many people.
and why anyone would build software on one server and forklift it onto another server is beyond me. this is always fraught with danger and is never a recommended procedure. this is precisely why technology such as docker was created.
anyhow - all is good. the purpose of this thread has been fulfilled and we have all, including myself, learnt a lot in the process of debugging.
keep up the great work everyone. when we all come together to support software like this we can achieve great things and everyone using nextcloud and the related add-ons benefits. iām loving all of the new development thatās taking place at the moment - itās a very exciting time for everyone
cheers, wizdude.
Ok, anyway, weāre all talking about the 20 seconds delay, so I think it is in-topic. Anyway, If this this a mistake I apologize.
Every package maintainer compile something on one system and then distribute it to other systems/people.
In my case I created my own package for libreoffice/loolwsd after compiling it, because surely I wonāt install all the dev-libraries and compiler on the web server in production. This is not dangerous, simply you must control what the debian package does, not somebody else. Iām not saying you must do it, but I have different needs then you.
Hi - I have read this (now dated) post. I am having a similar issue with collabora.
I have the server installed in a web accessible lxc container under ubuntu 18.04, and it is taking 20 seconds to āinitializeā (very simialr I believe to the problem posted hereā¦) - see screenshot below. After the 20-second delay, it loads files quite quickly (no issue), but the 20-second lag is driving me crazy. I have been unable to fix it:
Does anyone have any suggestions?
Andrew