mtu

[girish]

@Upuat so, the next step would be to do the curl from the server itself. The DNS resolution seems correct. Does ping and curl to say www.nextcloud.com work from the server?

[Upuat]

[girish]

@Upuat That seems ok too. It seems like maybe the messages inside nextcloud are out of date. Is there a way to clear those log messages?

[Upuat]

Messages cannot be cleaned. You can only delete the nextcloud.log file. And what does the log file and Nextcloud itself have to do with it? My Nextcloud app store is not working. Is it that hard to change the mtu value to 1450?

[girish]

@Upuat never seen such an issue with MTU before.

Reading up a bit on this topic, https://www.civo.com/learn/fixing-networking-for-docker says that the MTU must match. You can add the --mtu 1450 in /etc/systemd/system/docker.service.d/cloudron.conf . Do systemctl daemon-reload and then systemctl restart docker. If this works, copy cloudron.conf to a custom.conf since cloudron.conf is maintained by the platform and changes might get lost.

[Upuat]

@girish Thank you so much for the information!
But it wasn't enough. It is also necessary to bring the MTU value on all veth, br and docker0 network interfaces to mtu 1450.
Is it possible to do this? If possible, please tell me how.

[nebulon]

Given that wrong MTU seems rather obscure as an issue, maybe it is worth to come back to where you started. Did this issue come up suddenly or is it a fresh installation and the issue was there from the beginning?

Did you customize any of the networking setup after or during Ubuntu installation? I think chasing MTU sizes on interfaces is not the right approach to get a solid fix here, but this may be just a symptom of other things on the system which are not setup as default and might cause further issues down the line.

[Upuat]

It was a new installation on a new VPS. The problem is really in the mtu - there must be the same values. I decided radically for myself - I took another VPS. Thanks for the answers, the topic can be closed. I hope no one else will face such a problem.

[nebulon]

Which VPS provider was this and is the new VPS on the same provider but not facing those issues?

[Upuat]

Here is the answer from the provider:
"Your environment uses VLAN technology to create virtual networks. VXLAN reserves 50 bytes of headers for its own needs, which limits the maximum data transfer size in Ethernet packets to 1,500 bytes. For this reason, if you use the MTU 1500, the actual payload size will be reduced by 50 bytes, leaving 1,450 bytes for data transmission.

Unfortunately, therefore, the MTU on the interfaces in your configuration should be set to 1450 to avoid data transmission problems. An attempt to set the MTU above this on the ens3 interface will result in errors, since the networks in OpenStack are limited within these values."
I took another VPS from them, only from the old archive tariff. There is an mtu value of 1500.
I don't think this is a problem for the VPS provider.

[girish]

@Upuat maybe the veth interfaces are not updated by docker and have to be recreated. You can try cloudron-support --recreate-containers. This will delete all the docker stuff and recreate containers from scratch again. Maybe that helps. If that doesn't work either, you can go another level and try cloudron-support --recreate-docker . This recreates the bridge as well.

[girish]

@Upuat fwiw, cloudron uses a standard simple docker installation. You can just try this on a plain ubuntu VPS:

• Install docker
• Create a network - docker network create --subnet=172.18.0.0/16 --ip-range=172.18.0.0/20 --gateway 172.18.0.1 cloudron --ipv6 --subnet=fd00:c107:d509::/64
• docker run --network cloudron -ti cloudron/base:4.2.0 /bin/bash . You can try network access in this container

[Upuat]

@girish
https://forum.cloudron.io/post/95624

[Upuat]

Thanks again for the tips!