I'm running chgrp apache session command to make sure that my php session directory has apache write permissions but I am getting the error: chgrp: apache illegal group name.
I am following a set of instructions for this. The next step says to execute chmod g+wrx session to finish checking that it has write permissions.
Another StackOverflow post said: "illegal group name actually means that the group you're specifying doesn't exist. You need to either create the group, stop specifying a group, or specify a group that exists."
Unfortunately I'm not well-versed with Linux commands so I'm not sure how to do any of those. I followed this tutorial: http://fideloper.com/user-group-permissions-chmod-apache to set up apache and it worked when I substituted '_www' for user and group and used /Library/Webserver/Documents as the document root.
I don't know if that is the equivalent of executing 'chgrp apache session' and 'chmod g+wrx session' so would appreciate any clarification there. I also want to know how to set up those groups because some of the further instructions rely on them so I'd appreciate any help with that.
The 'session' that is referred to is likely the session.save_path="/private/var/tmp" that is the default session directory for OS X indicated in its php.ini file.
Would appreciate any clarification and advice on resolving this error. Thanks!
all groups are listed in /etc/group
you can see it's content by running less /etc/group
You can also see what process are running and who is running a process by looking at ps aux command.
It also is listed in httpd.conf (/etc/apache2/original/httpd.conf)
also in your question you mentioned the answer ("'_www' for user and group"), group is the same in both places.
So I have a user foo and the group www-data When the user creates a file/directory manually the permissions are:
foo:www-data --> rwx:r-x
And the user can then do what they like with that file/directory.
But when I use PHP to create a file or directory the permissions generated are
www-data:www-data --> rwx:r-x
Which then doesn't allow the user to do what they like with that file/directory.
So I have two options:
I have thought about adding the user foo to the group www-data but I have multiple virtual hosts and I don't want them to be able to edit each other's virtual domains (if that is even possible?!)
I have also thought about when creating the folder using PHP I will set the permissions to 777 but that seems like a big 'no no' (is it?)
What should I do?!
What you actually want to do is run different virtual hosts as different users. This is a link to some helpful answers for nginx:https://serverfault.com/questions/370820/user-per-virtual-host-in-nginx
The same concepts apply to Apache.
Edit:
The answers weren't clear to me when I read them, and there's a lot of info in the comments. The second answer by #Ricalsin is very informative and had a link that I used. Be sure to restart php-fps and nginx!
You could use phps chown() function to change the owner after creating the directory. See http://php.net/manual/en/function.chown.php. But you may need special privileges to successfully use the function, which may introduce a security issue.
Another option is the use of suEXEC in combination with SuexecUserGroup if you are running php-fpm (via FCGI instead of mod-php). In your virtual host file you will have to assign a user and a group to a virtual host via
SuexecUserGroup exampleuser examplegroup
With this directive activated all new directories and files created by php will have the specified user/group combination. Thats how a known webhost from germany does this, see the uberspace documentation (german only). More general information can be found here.
Using this solution you would avoid many security risks automatically. No need for 777 permissions, no possibility to see each others files etc.
Because with this approach, every user will have his own php instance running, its very easy and secure to allow them to use different php interpreter versions or own php.ini files.
hopefully someone can shed some light on my problem. I just reinstalled my OS (lubuntu 12.10) and have set up my local server. Everything seems to be working properly except for the one file I'm currently working on. When I try to run it in the browser, it downloads and/or gives a Server Error (HTTP Error 500).
I don't suppose it's an Apache or PHP problem since other files work just fine, but I don't think there's anything wrong with the code in the file in question.
What else could be causing this issue?
There is no need to "suppose" or devise "more than likely" cause or guess "what else".
HTTP Error 500 means there is something verbose in the server's error_log.
Just open it end get the exact explanation of the problem.
Please, do not take blind action, out of mere guess. You can make things worse.
This problem is more then likely caused by a permissions issue.
The Apache server runs as www-data:www-data. What this means is that it is possible to have some permission issues with files that were created by another user.
To solve this, you should either add your user to the www-data group and set the /var/www directory to inherit the group www-data, or you can use chown to change the ownership of all the files to be on the www-data group.
To keep security in your system, you should also make sure that all your files have a permission set of 660, meaning that the owner and anybody of the user group of the file can both read and write, but any other user will not be able to do anything with it.
If you have a php script that does run more than 30 seconds (default) you have to change value of max_execution_time by using ini_set function.
I'm running a LAMP stack on a linode. The Ubuntu version is Lucid.
When a PHP script executes a mkdir() or move_uploaded_file command, the newly created folder/file winds up being owned by a unix user 'Grusha'. I did create this user, but it should not be owning files. The web folder overall is owned by www-data, as is (by extension) the containing folder inside which the new folder/files are moving.
The user's /etc/passwd line is like this:
grusha:x:1000:1003:,,,:/home/grusha:/bin/bash
And /etc/group is this:
grusha:x:1003:
Grusha owns the PHP sessions as they're created too, although nothing else. No processes or files on the system run as Grusha either.
I log in with a public key, and the user who that goes through is not Grusha (nor root).
When I delete Grusha, I can no longer restart Apache. I get bad username and the restart fails. My PHP sessions also don't work.
So in the end I add Grusha again and the server will start and everything works except that scripts make files owned by Grusha, not www-data.
I've been looking around as much as possible, but can't find any info. My httpd.conf is empty. My apache2.conf contains these lines:
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
And those variables are defined as www-data in /etc/apache2/envars.
If anyone has any suggestions I'd be grateful.
Thanks a lot,
Elliot
The suPHP module is probably enabled. Its function is to let PHP code execute under the user ID of the user who owns the scripts, instead of www-data, which can be very insecure on a shared server. Try turning off suPHP by deleting /etc/apache2/mods-enabled/suphp.load and /etc/apache2/mods-enabled/suphp.conf.
On the off chance that's not the problem, check that the user grusha doesn't actually have the same numeric user ID as www-data (in /etc/passwd). That's probably unlikely though.
Ah, this is solved. Apologies.
I had mpm directives in /etc/apache2/sites-enabled/ that caused apache to run as grusha.
Unsure how that happened, but it's fixed in any case.
Thanks to you both for thinking about my problem.
when I uploaded the script to the server I got this error
Warning: Unknown: open(/tmp/sess_58f54ee6a828f04116c2ed97664497b2, O_RDWR) failed: Permission denied (13) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0
The error appeared when I call session_start(), although I set the permission of /tmp folder to 777.
Change session path where you can write data or contact server administrator about /tmp problem
http://php.net/manual/en/function.session-save-path.php
you will need to change your session.save_path php.ini directive
You can do that using session_save_path
If you have SSH access, here is how to correct the permission and ownership
sudo chown -R NAME_OF_USER /tmp
Replace NAME_OF_USER by the user under which runs php. You can find it by simply putting these lines in a php file:
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
exit;
Check that you're not running into diskspace issues. If all the permissions are correct (and 777 ought to do it for you), then you might still get this error (for some versions of PHP and Apache) if there isn't enough space to write to the disk.
I had this problem in the following situation:
I filled some session vars with PHP
While the session was still active, I changed from PHP 5.4 to 5.3 on my host.
Reloading the page gave the error, described above.
Reset the PHP version to 5.4 again.
Used session_unset(); and session_destroy(); to clean the current session.
Changed the PHP version back to 5.3.
Now it works again.
Conclusion: For an irrelevant reason I had to change my PHP version, and while switching with sessions alive, the sessions get corrupted.
I realize that this is an old post, however I just ran into this problem, and found an easy solution.
For me, the issue was happening with one of my websites deployed locally. I hadn't tried accessing the websites using other browsers, but it was happening every time I tried to access this site via Chrome. I decided to go into the Chrome developer tools, under the application tab -- and clicking "Clear Storage". Voila -- everything is working like magic again.
Hope this helps someone else!
Additionally, you may want to use ini_set('session.save_path', '/dir/here'); assuming you have access to this function. The other ways suggested are valid.
I've just had exactly the same problem with one of my PHP scripts and I was like what did I break 'cos it worked perfectly the day before and I'm running it from my own local Puppy Linux machine so it's not even a host or anything.
The only thing I'd been doing before that was trying to get Java to work in the web browser, so some how I'd managed to get Java to work but broke PHP - oops!
Anyway I did remember that whilst trying to get Java to work I had deleted the contents of the /tmp folder to wipe anything out that may be causing a problem (it actually turned out with Java I was using the old plugin oij with the new Firefox)
To solve this problem I opened up Rox File Manager, went to the / folder and right clicked on the tmp folder -> Mount Point 'tmp' and clicked properties.
I noticed the permissions were set as Owner - Read, Write, Exec, but Group and World were only set at Read and Exec and not Write. I put a tick in Write for both Group and World and now PHP works fine again.
I don't know at what point the permissions for tmp must have changed but for PHP to use them it must be set to have Write permissions.
Add following line
ini_set('session.save_path', getcwd() . '/tmp');
before
session_start();
if you are using Apache web server, the quick fix is to go to your command line and type:
open /etc/apache2/
then from the window opened, open the file called httpd.conf and search for User or Group change these 2 lines to:
User _www
Group _www
This is because you want your server to have permission to your systems directories, especially you want to change the User or you can leave your Group to either staff or admin.
I had the same problem of permission, but on /var/lib/php/session/.
To fix it, I deleted the file and restarted php-fpm.
rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
sudo service php5.6-fpm restart
Now all works well.
For me the problem seems to be a WHM bug!
I have a bunch of add on domains and all work fine but with a subdomain it brings this error.
Strange thing but if I use the full URL with the main domain it works fine:
main-domain.com/my.subdomain.com
If I use the subdomain directly it brings "Permission denied (13)":
my.subdomain.com
The thing is all addon domains root is:
/home/xx/
But for my subdomain, don't know why, the root is: (I shouldn't have access to that dir)
/
So it´s really trying to reach: /tmp instead of /home/xx/tmp
Which also exists but don't have the right permissions
To clarify this are examples of the whole path:
/home/my-account/public_html
/home/my-account/tmp
/tmp
The workaround I used was:
session_save_path('/home/my-account/tmp');
session_start();
Using PHP 5.6 I had already used session_save_path() to point to a directory within the domain's structure. It worked fine until I upgraded to PHP 7.0, at which time I received the noted error. At PHP.net I found several comments that indicated assigning a direct path didn't always work, so I used their suggestion.
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
worked perfectly. Remember to change /../session to the relative location of your actual session directory.
If :
session.gc_probability > 0
session files are created by different user(s) (e.g. root and apache).
session files are all stored in the same place (e.g. /var/lib/php/session)
Then you'll see this error when e.g. the Apache PHP process attempts to run garbage collection on the session files.
Fixes :
Reconfigure PHP so gc_probability is 0, and have a cron job removing the old/stale file(s).
Have each different user save their session files in separate place(s) (session_save_path() etc).
I initially had this issue due to nginx owning the /tmp location and php-fpm was running under 'apache' user and group due to the www.conf. I swapped out the user/group in that file and then it worked ok. You may want to check <?php echo exec('whoami'); ?> to verify.
In my case the problem was SELINUX not allowing this.
A helpful command to get suggestions on how to fix this:
sealert -a /var/log/audit/audit.log
If you want to rule out SELINUX, try disabling it for a moment. If that fixes the issue then that is the problem.