[Bug]: Adding server with user other than root changes ownership of /

[icanos]

Error Message and Logs

After updating to 4.0.0-beta.414 and adding a server to Coolify the process of adding the server changes the ownership of the filesystem / to the user selected in the dialog.

Steps to Reproduce

1. Install a new server, I've tested this multiple times with AlmaLinux 9.5 and install with a user other than 'root' with administrative privileges
2. Install Docker as per instructions
3. Add the server to Coolify and choose the user that you installed the server with
4. Add the server and validate it
5. You will get an error in Coolify saying that the ownership of /etc/sudoers are wrong
6. SSH to the server and run 'ls -la' to see the filesystem ownership changed

Example Repository URL

No response

Coolify Version

v.4.0.0-beta.414

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

AlmaLinux 9.5 (Teal Serval)

Additional Information

No response

[djsisson]

this has to be one of the worst bugs ive ever seen

it might be related to the proxy_path being set to /

this has been fixed in 415, but not sure if its related

[andrasbacsai]

@icanos Can you please try to install v415 and let us know if it happens with it as well?

[mikesoaps]

We have just lost sudo access to 60% of our critical VMs due to this bug :(
We love Coolify but would love a resolution to this please.

[icanos]

I just upgraded to v415 and configured a new server and can confirm that the filesystem permissions does not change from root to our selected username.

[icanos]

@mikesoaps you should be able to boot into single user mode and restore permissions to /etc/sudoers (or the entire filesystem), but it will require manual and tedious work, restoring all permissions (if backups are missing).

[Megajin]

Same here, just lost control over my control Coolify server. I have a non root setup but somehow, after updating, my user (coolify user) owned everything. Now I am unable to reclaim control, except to use backups.

Update:
It seems this happens only if I go to my dnyamic proxy settings. Strange...

[equa2k9]

Same problem, two servers just broken
`
sudo: /etc/sudo.conf is owned by uid 1000, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

sudo: /etc/sudo.conf is owned by uid 1000, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
sudo: /etc/sudo.conf is owned by uid 1000, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
sudo: /etc/sudo.conf is owned by uid 1000, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
`

I fixed it through hetzner's "rescue mode" but after starting proxy I got same error

[equa2k9]

Found a solution for hetzner:

1. Upgrade your coolify to 415
2. Go to your hetzner dashboard of broken server
3. Tab "Rescue" -> click "Enable rescue & power cycle"
4. Wait and connect to "rescue" server ssh root@ip-of-your-server
5. then commands:

# Mount it (assuming /dev/sda1 is your root partition)
mkdir -p /mnt/system
mount /dev/sda1 /mnt/system 

chown root:root /mnt/system/usr/bin/sudo && chmod 4755 /mnt/system/usr/bin/sudo && chown root:root /mnt/system/etc/sudo.conf && chown root:root /mnt/system/etc/sudoers && chmod 440 /mnt/system/etc/sudoers && chown -R root:root /mnt/system/etc/sudoers.d/ && chmod 755 /mnt/system/etc/sudoers.d/ && find /mnt/system/etc/sudoers.d/ -type f -exec chmod 440 {} \;

reboot

after that sudo must working fine

[Megajin]

🛠️ Recovery Guide for Coolify Permission Issues (Hetzner VPS)

Hey folks,

I approached the permission issue from a different angle — all my servers are hosted across various locations with Hetzner, and I'm relying heavily on certificate-based authentication with root login disabled.

---

Here’s a step-by-step guide based on what worked for me:

✅ Preparation & Initial Access

1. Use Hetzner's backup feature to restore access to your VPS.
2. Log in to your VPS and switch to the root user: su -
   Don’t have the root password but still have sudo rights?
   Set a new one with: sudo passwd root

---

🔐 Back Up Permissions Before Updating

3. Create a backup of all current file permissions, owners, and groups: sudo find / -xdev -printf '%p|%u|%g|%m\n' > permissions-backup.txt
4. Create a restore script to revert changes if needed: nano restore-permissions.sh
5. Add the following content:

#!/bin/bash

while IFS='|' read -r path user group mode; do
  sudo chown "$user:$group" "$path"
  sudo chmod "$mode" "$path"
done < permissions-backup.txt

6. Make the script executable: chmod +x restore-permissions.sh
7. Create a fresh backup of your VPS in the Hetzner dashboard.

---

⚠️ Updating Coolify & Monitoring

8. Stay logged in via SSH as root on all affected servers.

9. Proceed to update Coolify and test changes through the dashboard.
   I noticed the issue appeared while modifying dynamic proxy settings,
   even though I had no actual proxies configured.

10. Periodically verify key permission paths: ls -lah /

11. If something breaks, run the restore script to reset original permissions: ./restore-permissions.sh

---

🔁 Alternate Solutions

• Revert to a backup taken before a faulty update (in my case, before version 413) and try updating again from there.
• Alternatively, the solution suggested by @equa2k9 comment also seems to work well.

---

@andrasbacsai maybe this could be implemented as a "before update hooks"?

[andrasbacsai]

If anyone needs help to fix this issue, contact me via email or Discord.
https://coolify.io/docs/get-started/support