-
Hello everyone.
root@cv4181645:~# ip a | grep -e "ens3" -e "docker0"
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
inet 192.168.0.32/24 metric 100 brd 192.168.0.255 scope global dynamic ens3
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
How do I change the mtu in cloudron to 1450? -
@Upuat Can you give more context to the question? Why do you want to change the MTU? Did you hit any problems?
But in general, Cloudron is just running on Ubuntu. If you use netplan for your interface, you can set it there. https://hoppsjots.org/mtu.html for example
-
https://netplan.readthedocs.io/en/stable/netplan-yaml/ might be a better doc link . Can't deep link but search for "mtu"
-
-
@Upuat The issue here seems to be DNS related and not MTU related. if you open a Web Terminal in nextcloud and then just
curl https://www.nextcloud.com
does it work? If it fails, tryhost www.nextcloud.com
. Please paste those errors. -
@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 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 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
. Dosystemctl daemon-reload
and thensystemctl 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. -
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.
-
-
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. -
@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 trycloudron-support --recreate-docker
. This recreates the bridge as well. -
@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