Hardware: VPS bought online YunoHost version: 11.2.12 I have access to my server : through the webadmin Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes If yes, please explain:
I “accidentally” changed the ownership of the www folder
Description of my issue
I’m sorry if this is something I should know or if it’s something easy to solve, but I’m quite panicking and I cannot find an answer anywhere.
As stated in the description, I was trying to find a solution for a problem and I stupidly changed the ownership of the “www” folder inside “var”. Is there a way to reverse this process and go back to normal or did I just forbaid everyone to access or see my sites forever?! (if I try to access them, I get a 403 Forbidden nginx error page)
I still can access the server via command line.
I’m sorry if this is not clear.
www is owned by root but every folder in it has different ownership depending on the apps.
Did you change the ownership recursively?
What is the output of sudo ls -lh /var/www
hi @jarod5001 thanks for the reply.
Once I got back on my feet I thought about confronting the “corrupted” www folder permissions with another server where I also installed yunohost and a bunch of applications.
I did it recursively and so the ownership changed for every folder.
Now I’m going back folder by folder and assign ownership to each and every user and group.
Pheew… thanks and sorry for the panick. The thread can be closed.
If anyone will ever do what I did:
the ownership of www is root:root
each subfolder apart from .well-known and html have this ownership [name of the application]:www-data
That is incorrect, it depends on the app. Some have $app:$app as owners. A simpler, but longer way would be to run a forced-upgrade on all apps, as one of the steps is to reapply ownership on the directories.
Example
ls -la /var/www
total 116
drwxr-xr-x+ 27 root root 4096 Jun 27 19:27 .
drwxr-xr-x 14 root root 4096 Jun 16 05:27 ..
drwxr-x--- 12 aeneria www-data 4096 Jan 17 17:15 aeneria
drwxr-x--- 4 cinny www-data 4096 Jun 27 19:26 cinny
drwxr-x--- 3 conduit root 12288 Jun 27 19:49 conduit
drwxr-x--- 16 cryptpad www-data 4096 Jul 31 2023 cryptpad
drwxr-x--- 14 cypht www-data 4096 Jun 6 19:57 cypht
drwxr-x--- 3 dispatch www-data 4096 Aug 1 2023 dispatch
drwxr-x--- 16 element www-data 4096 Jun 27 19:27 element
drwxr-xr-x 2 root root 4096 May 2 20:09 html
drwxr-x--- 6 immich immich 4096 May 20 09:03 immich
drwxr-x--- 13 nextcloud www-data 4096 Jun 27 21:38 nextcloud
drwxr-x--- 13 nodered www-data 4096 Jun 27 19:06 nodered
drwxr-x--- 4 ntfy ntfy 4096 May 20 07:40 ntfy
drwxr-x--- 5 owntracks www-data 4096 Jun 23 16:40 owntracks
drwxr-x--- 13 paperless-ngx paperless-ngx 4096 Jun 29 15:00 paperless-ngx
drwxr-x--- 13 phpmyadmin www-data 4096 Nov 3 2023 phpmyadmin
drwxr-x--- 17 roundcube www-data 4096 May 26 08:42 roundcube
drwxr-x--- 9 signaturepdf www-data 4096 Jan 3 2024 signaturepdf
drwxr-x--- 3 snappymail www-data 4096 May 28 12:00 snappymail
drwxr-x--- 2 unattended_upgrades unattended_upgrades 4096 Feb 13 08:27 unattended_upgrades
drwxr-x--- 4 vaultwarden vaultwarden 4096 Mar 16 12:57 vaultwarden
drwxr-xr-x 73 root root 4096 Jul 7 19:18 .well-known
drwxr-x--- 13 wetty wetty 4096 Mar 31 19:14 wetty
drwxr-x--- 3 wireguard wireguard 4096 May 20 07:45 wireguard
drwxr-x--- 15 yunorunner www-data 4096 May 2 23:38 yunorunner
drwxr-x--- 2 zerotier zerotier 4096 May 17 22:38 zerotier
Thanks, I didn’t know that, I only had applications that follow this rule, so I assumed it worked like this (I just found out that onlyoffice needs different owner and group).
Thanks and sorry again