Cool. Thanks for the definitive answers all. Cheers.

OK, I have fixed the unbound issue with IPv6. It's an upstream bug but I have made a workaround for the moment. Fix will be part of 7.3.5 (released next week).

This is fixed in 7.3.5 (will be released next week).

@girish said in Restrict Dashboard Access - Cloudron v6.1.2: @potemkin_ai UFW and Docker are not compatible. I haven't looked into the repo you linked yet. I didn't test the solution yet, found it with people referring as a working one, so I have hopes. The idea is to modify /etc/ufw/after.rules to contain: # BEGIN UFW AND DOCKER *filter :ufw-user-forward - [0:0] :ufw-docker-logging-deny - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j ufw-user-forward -A DOCKER-USER -j RETURN -s 10.0.0.0/8 -A DOCKER-USER -j RETURN -s 172.16.0.0/12 -A DOCKER-USER -j RETURN -s 192.168.0.0/16 -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12 -A DOCKER-USER -j RETURN -A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW DOCKER BLOCK] " -A ufw-docker-logging-deny -j DROP COMMIT # END UFW AND DOCKER Why not just enable 2FA on the dashboard? It's a different security layer. 2FA relies on the code, which is much more complicated, as opposed to network level filtering. What is more complicated could have more issues. So, whenever possible, I close any code from outside access - everything have bugs, some of them are in security space, even if you are OpenBSD Do you believe this could become part of the system? I would really like to deny from all with allow from xxx.xxx.xxx.xxx with periodic firewall disable for let's encrypt.

@Vladimir Sounds like a popular site with lots of traffic. Sounds like you found one reason to be the translation plugin. You should be able to view the apache logs and monitor for errors, similarly for long DB calls which might make things wait, but then you'd notice site slowness from that too.

@AgentM which dns provider are you using? If you go to Domains -> Renew all certs, can you check the logs as to why it is it not getting the certs?

@nebulon Thank you, I will investigate today and let you know.

@brandthedwarf I finally did it. I'm not a technical person and just followed the instructions running it locally

@ChristopherMag I will fix it up now for the next release. We were kinda aware of this already, but wanted the last release out sooner rather than later.

Increasing concurrency and memory, as suggested here, works: https://forum.cloudron.io/topic/8219/backup-hangs/14 Found at Menu > Backups > Configure > Advanced. Tip to @girish / dev team: adding in a note on the app > backups page would probably be very helpful. Restore failing? Try [increasing memory and concurrency] [image: 1671464606037-70c14a75-3889-4c9e-abef-799231c38e76-image-resized.png]

@nebulon it's up again

If you use something like Cloudflare for DNS then you have to use the raw IP of your server to connect via SSH, since Cloudflare will not proxy other ports besides 443. Cloudron also has rate-limits setup via iptables but those are hard to hit while manually trying to connect and after a short time your local IP will be able to connect again, so I doubt this is what you are hitting. Also I am not sure what you mean by ping returning 0.0.0.0?

yes, if the backup config has a password set, the UI will expect it to be entered before you can restore. You can use the top right menu to mark this as resolved.

@roofboard said in Box Crashes.: After running the apt update / upgrade the problem resolved. Please be very aware that you are not supposed to apt upgrade on your own (outside the OS upgrade procedure). This may break your installation and might be the reason of trouble you run into. [image: 1671336582609-greherh-2.png]

@girish I restored from a backup to get it working..

@girish my bad! You can blame user error for this one Hetzner StorageBoxes need a different path when sub-accounts are used, which I forgot to note in my docu and went changing things. Here's to anyone dealing with change management professionally, ITIL or otherwise, you are a must-have no matter how often peeps complain about 'red tape' There's a reason why I keep documenting things but no AI or home assistant has been invented yet to make me actually remember to stick to it Notes to self: Before changing critical things like backups(!) make sure to follow the documentation. Do not disable critical features on accounts like CIFS access (d'oh). Also, make sure to test changes thoroughly before committing to them. Also also, enjoy Cloudron and the awesome people making it a super nice place to be