Debian: Apache not using correct owner and group

I just installed Grav and I'm currently learning from the Grav documentation and playing with creating folders/files. I have the exact same problem as mentioned in this old post: /forum/plugins/administration-panel-vs-the-cli-permissions-t9252

I'm not a power-user of command line, so I don't know how to fix this.
Can someone give some help ?
I'm on Debian 12 by the way.

I'm currently using the Apache server only locally.
I saw this in the documentation :

• PHP/Webserver runs with different accounts but same Group

  By using a shared Group between your user and PHP/Webserver account with 775 and 664 permissions you ensure that even though you have two different accounts, both will have Read/Write access to the files. You should also probably set a umask 0002 on the root so that new files are created with the proper permissions.

I dit "umask 0002" but nothing changes, and I'm not sure how to set the right permissions. Maybe I'll need to use the script, but I'd rather understand how to do it the right way, the script looks like a workaround, doesn't it ?

I also tried to change Apaches user variables as follow :

export APACHE_RUN_USER=newuser
export APACHE_RUN_GROUP=newuser

And then

chown --recursive newuser:www-data /var/www/my_website

But it won't solve the problem

@Youle,

Disclaimer: Infrastructure is not my forte...

I'm using Ubuntu 24.04 inside WSL on Windows 11 and use the "PHP/Webserver runs with the same user that edits the files. (Preferred)" approach.

Replacing Apache's default account

By default, Apache uses account www-data to read/write files. For locale development it is however easier to have Apache use your own Ubuntu account.

• Open the envars file to change the account name:
  BASHCopy

  sudo nano /etc/apache2/envvars
  

• Replace in below lines www-data with the name of your Ubuntu account:

  TXTCopy

  export APACHE_RUN_USER=www-data
  export APACHE_RUN_GROUP=www-data
  

• Save the file by pressing Ctrl<small>+</small>O, and hit Enter to confirm. Exit with Ctrl<small>+</small>X.
  (In the command bar: ^ meants Ctrl and M means Alt)
• Restart Apache
  BASHCopy

  sudo service apache2 start
  

Apache and CLI will now both:

• use your permissions to access files and
• create files owned by you.

Thank you for trying to help. Unfortunateley I did that already.
But even with the configuration set with my username and usergroup, Grav will still create new pages using www-data as username and group, with the wrong permissions.
I don't know it this is a bug from Grav or there's something I don't understand.

@Youle,

Unfortunateley I did that already.

Well, you mentioned a mix of several possible solutions, which could cause issues. I just listed the only steps I took to solve the issue in my environment.

• No umask 0002
• No chown --recursive newuser:www-data /var/www/my_website

All my files and directories have my account as group and user.

I don’t know it this is a bug from Grav

Grav does not have the habit to change the user or group on the fly.

To test if Apache itself is the cause:

• In folder /var/www/my_website, copy index.php to index.php.org

• Replace content of index.php with:

  PHPCopy

  <?php
  
  file_put_contents('test.txt', 'My data');
  
  die('Now, check the owner and group of file "test.txt"');
  

@pamtbaau:

PHPCopy

<?php

file_put_contents('test.txt', 'My data');

die('Now, check the owner and group of file "test.txt"');

Owner and group are "www-data"

@Youle,

Owner and group are “www-data”

Ergo:

• Apache is not using your account as owner and group...
  Which it should, if you changed export APACHE_RUN_USER=www-data and export APACHE_RUN_GROUP=www-data correctly with your account name.
• We can safely conclude that Grav is not the problem, since it was not involved in the web request due to the altered index.php.

Ok thank you for your help.
I don't know what to do then :/
I'm going to look for some documentation on Apache.

@Youle, Maybe this similar post for Debian might help: Why doesn't apache2 respect my envvars file?

In general, apache2 should not be invoked directly, but rather should
be invoked via /etc/init.d/apache2 or apache2ctl. The default Debian
configuration requires environment variables that are defined in
/etc/apache2/envvars and are not available if apache2 is
started directly. However, apache2ctl can be used to pass arbitrary
arguments to apache2.

I've found this post too, tried to restart apache with 'apache2ctl' command, tried again after reloading the admin backend, to no avail.

I've run this command :
sudo apache2ctl -S

And everything seems ok, it gives me the right username.
Still searching !

@pamtbaau:
/etc/init.d/apache2

Now something is happening at last.
I've run the following commande :
/etc/init.d/apache2 restart

And now Grav can't work properly anymore.
I'm happy I get errors, this means the envvars file is now taken into account 😂
So it seems Apache can't load Grav properly when I set the user to something else than www-data.

@Youle, This is how I start Apache2 (on Ubuntu though): sudo service apache2 restart

About what to set in the envvars file, should I set My_user / My_usergroup or My_user / www-data ? I tried both actually, but I'm not sure what is best. Both make the same errors.

I've found this :

This works as a charm! thank you. the only I would add: sudo chown big_dog.big_dog /var/lock/apache2
Also probably you will need sudo chown big_dog.big_dog -R /var/log/apache2

– Kostanos Commented Dec 18, 2013 at 13:14

And this :

But now I get Warning: SessionHandler::read(): open(/var/lib/php/sessions/sess_ft772juh1blqnqjvhli7tkem3l, O_RDWR) failed: Permission denied EDIT: I solved it, by deleting the file /var/lib/php/sessions/sess_ft772juh1blqnqjvhli7tkem3l

– [Black]

I wanted to try to remove the session file, but I can't : www-data owns it and I won't be allowed to delete it.

@Youle, I'm using the following:

export APACHE_RUN_USER=myaccount
export APACHE_RUN_GROUP=myaccount

I've set that a long time ago and now realize that the group myaccount doesn't even exist. Bit stupid maybe, but never seen any errors/problems though...

Didn't I say: "Infrastructure is not my forte…"?

Wooooow !!! I succeded ! So haaaaapy 🙂
Soooo, in order to remove /var/lib/php/sessions/sess*
I've run this command, found here : https://serverfault.com/questions/851255/rm-rf-cannot-delete-session-files

sudo sh -c "rm -rf /var/lib/php/sessions/*"

Now everything works properly, the new pages I create within the backend have the right owner and permissions, and as a bonus, the backend got translated into french :)

Thank you for your support @pamtbaau

@Youle, For the benefit of the community, would you mind describing what caused the problem and what steps were needed to solve the issue and where you found the solution?

@Youle,

what’s not clear to you ?

It's not about things being clear to me, but about clarity for the community. It's hard to digest all replies in order to get a full picture of the cause of the problem and its solution.

Hello there.
I'm very new to the Grav users community, I'm still learning and experimenting with Grav. In my local Linux Ubuntu 24 laptop I have experienced the same weird behaviors described already here.
After edited the /etc//apache2/envars file

export APACHE_RUN_USER=me_user
export APACHE_RUN_GROUP=me_user

After reloaded then restarted apache2 some weird things happened and I have simply restarted my laptop and get the things done.
However, I decided later to change the run_group for the apache2 back to
www-data, letting the apache2 user as me_user.
The umask and permisions set recursivelly in /var/html/grav-test but I still shoul enter the admin pasword everytime I need to edit files in /var/www/html/grav-test.
I'm using Kubuntu 2404 Plasma and I guess I have to work a little bit as it is some room for improvement.
Meantime I'm also using
bin/grav server
command in my user home location, for testing purposes as well.
off-topic: I have found the Gantry5 framework and I'm testing that as well.

Many thanks to the people that have created Gravity, this beautiful thing in the Content Making Universe!

About needing to enter the admin password each time you want to access to /var/www: I resolved that by doing a symbolic link between /var/www/my-site and /home/me/www/my-site. You can only securely do that if you're on a local configuration.
How to do this : https://forum.ubuntu-fr.org/viewtopic.php?id=936071

Maybe this can help someone having problems with permissions of the Grav pages.

For some unknown reason, some Grav user pages had permissions set to root, and therefore reading was denied when trying to read these pages.
Through the terminal, navigate to Grav root folder.
(chown -R user:group folder)

cd /var/www/vhost/.....
chown -R NameOfDomainUserGroup_xyz:psaserv .

(The ending space dot . is important.)

This resolved the issue. While managing the pages, I assume that one must not be logged in as root user, but as the domain user.
I hope this sheds some light as to what may be an issue with permissions.