I am trying to do a really basic rename of a file to another name in my code. However there seems to be some ownership/permissions problem that is stopping this working correctly.
This is my (simplified) code:
ini_set ("display_errors", "1");
error_reporting(E_ALL);
$St_Num = '7940';
$Co_Code = 'RDCO2';
rename("$St_Num-$Co_Code-1.jpg", "$St_Num-$Co_Code-4.jpg");
These are my permissions of the files I am trying to change:
Code:
-rw-r--r-- 1 apache dev 4065 Oct 22 17:57 7940-RDCO2-3.jpg
-rw-r--r-- 1 apache dev 4276 Oct 28 09:39 7940-RDCO2-2.jpg
-rw-r--r-- 1 apache dev 4336 Oct 28 09:39 7940-RDCO2-1.jpg
This code was working, and it seemed to work when apache was the creator of the file. However, when I changed the ownership to 'apache' it stopped working. Does PHP/Apache have a concept of knowing who the creator of a file was? Would this stop a rename() from working?
I'm stumped with this one now - any help is appreciated.
Thanks,
Picco
do chmod(0666) [on the server] to give all users (including apache) write rights
You have to set read-write ownership for that specific directory to public-www.
Related
UPDATE: This issue was caused by the server request timing out before the script completed.*
I have legacy code running on a shared LAMP host (nearlyfreespeech.net), and I recently added a new script that refuses to work in production.
My apache error logs show the message End of script output before headers: switch.php, and I get 500 statuses when trying to trigger the script with a web client.
According to other StackOverflow posts, this error message is usually due to a file permissions error. However, the file permissions on the new script are the same as all the others.
Here are the relevant file permissions:
-rw-rw-r-- 1 235430 235430 1655 Jul 6 18:05 switch.php
drwxrwxr-x 2 235430 235430 18 Jul 1 21:05 auth/
-rw-rw-r-- 1 235430 235430 13 Aug 24 2015 auth/.htaccess
-rw-rw-r-- 1 235430 235430 280 Jul 1 21:05 auth/cloudsaves.2.php
-rw-rw-r-- 1 235430 235430 880 Aug 28 2015 auth/cloudsaves.php
-rw-r--r-- 1 235430 web 15580 Jul 1 21:05 auth/rumpus_migration.php
With these include() heirarchies:
switch.php -> auth/cloudsaves.php (works)
switch.php -> auth/cloudsaves.2.php <- auth/rumpus_migration.php (does not work)
All requests are for switch.php and include a parameter value causing either auth/cloudsaves.php or auth/cloudsaves.2.php to be included.
In my local test environment everything works just fine. In production when I use the parameter that causes switch.php to include the cloudsaves.2.php script I get the error.
I've tried changing the group and permissions on rumpus_migration.php and cloudsaves.2.php to exactly match other files that are properly being included by the parent switch.php script, always with the same outcome. This new script (cloudsaves.2.php) is the only script included by switch.php that itself includes another script.
I'm not familiar with Apache or PHP, and the production code is on a shared host where I have extremely limited admin access. The fact that the code works locally but not in production makes it seem that a permissions issue is a likely culprit, but I don't know how to move forward since none of the working permissions options seem to fix it.
The issue was that the request was timing out before the script completed, due to a long-running database query.
So that generic End of script output before headers error can be caused by server timeouts as well as file permissions issues.
We have been struggling with cURL since we've had our new server (no issues previously). In the last 6 months we've searched and tried to fix the issue at the root, with no success.
We are running an Ubuntu 16.04 server, with a Codeigniter project on PHP and Nginx.
The (composer) package we are currently having the issue with is the Mailgun API (which extends the composer package php-http)
Below is the error that we get when connecting via cURL
An uncaught Exception was encountered
Type: Http\Client\Exception\RequestException
Message: error setting certificate verify locations: CAfile: /etc/ssl/certs/ca-bundle.crt CApath: /etc/ssl/certs
Filename: /var/www/ domain /vendor/php-http/curl-client/src/Client.php
Line Number: 137
The only solution that has worked for us so far disabling CURLOPT_SSL_VERIFYPEER, but we've had to do that inside the composer package, which obviously is not a proper solution.
I'm hoping someone here can please shed some light on how we might be able to resolve the issue.
What we have tried so far:
Checked the date on the server
Disable CURLOPT_SSL_VERIFYPEER, but not a viable solution
Set .curlrc file (but issue is that webserver user is executing, so no place to put it?
Checked the /etc/ssl/certs/ folder to see if the files exist.
sudo update-ca-certificates --fresh
File permissions on the folder
root#Ubuntu-1604-xenial-64-minimal /etc/ssl/certs # ls -la ca*
lrwxrwxrwx 1 root root 37 Apr 26 11:17 ca6e4ad9.0 -> ePKI_Root_Certification_Authority.pem
-rwxrwxrwx 1 root root 274340 Mar 8 17:09 ca-bundle.crt
-rwxrwxrwx 1 root root 274340 Apr 26 11:25 ca-certificates.crt
-rwxrwxrwx 1 root root 261889 Jan 18 06:12 cacert.pem
-rwxrwxrwx 1 root root 261889 Jan 18 06:12 cacert.pem.txt
As I have been struggling with this for a long time and haven't been able to find the answer anywhere, but found it due to the help of # Deadooshka in a not so related post, I'll leave my question and answer here.
For me the solution what that the /etc/ssl folder needed execute permission. I have no idea where this has gone wrong, but the solution for me was the following:
$ /etc # chmod o+x ssl
When the permissions were wrong, I could not read the certificate file using file_get_contents(/etc/ssl/certs/ca-certificates.crt) in a PHP script in the web root, executed from the browser. After the fix, the file was read.
I have a new file server (FilServerB) that I have had up and running for a few months. I've been moving all my processing servers over to use FileServerB for their PHP code. I recently found a server (server name is susan) that I had missed, and it was still connecting to the old file server (FileServerA). When I mounted FileServerB on susan, none of the code would run on it anymore. In ssh, when I go to a directory with PHP code in it, and run "php cleanISL.php", it says this:
Fatal error: Unknown: Failed opening required 'cleanISL.php' (include_path='.:/local/online/live/common:/local/online/pear') in Unknown on line 0
If I create a new php file on the local filesystem, it runs just fine. If I try an is_file or is_directory for a file or directory that I know exists on the mounted filesystem, it always returns false. However, I can glob directories, and it shows the files in there just fine.
I've tried changing (and removing completely) my include_path, I've tried going back to the old file server (which works), and then unmounting the old one and mounting the new one the exact same way (still doesn't work), and a few other things. I can't tell if the issue is with PHP, or somehow with the way the server is mounted, or something else. I've made sure SELINUX is disabled. The issue seems to be only affecting PHP, and only when I mount the new FileServerB, and only on this particular server (susan). But I'm baffled at what could be causing it or how to fix it.
Also, I have mounts to other servers (for data/media) on this same server (susan), and those work just fine, ie, PHP can see and read files on those mounts too.
UPDATE 1, strace info
This is the relevant line of the strace on a failed is_dir:
stat64("/online/live/tools/test/fixes/", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
And this is the output of a stat command on the same dir:
File: `/online/live/tools/test/fixes/'
Size: 4096 Blocks: 8 IO Block: 32768 directory
Device: 18h/24d Inode: 11815229588 Links: 3
Access: (0775/drwxrwxr-x) Uid: ( 1004/ UNKNOWN) Gid: ( 1010/ UNKNOWN)
Access: 2016-07-06 07:28:46.606024801 -0600
Modify: 2016-06-24 16:23:42.206547505 -0600
Change: 2016-06-24 16:23:42.206547505 -0600
And this is a namei -m result:
dr-xr-xr-x /
lrwxrwxrwx online -> /mnt/code/online/
dr-xr-xr-x /
drwxr-xr-x mnt
drwxr-xr-x code
drwxr-xr-x online
drwxrwxrwx live
drwxrwxr-x tools
drwxrwxr-x test
drwxrwxr-x fixes
I'm on a relatively fresh install of Ubuntu and this is the first time I've used the local web server on it.
The problem I have is that when I try and access a php file I get a 500 error.
To try and solve it I've:
Renamed index.html to index.php in /var/www to make sure it's not a virtualhost error (standard "it works" file)
given 0777 permissions to both /var/www and the index.php file
made www-data the owner of the directory and the file
made www-data the group for the directory and the file
checked the error log
trawled Google
The error log shows:
[Sat Sep 07 13:18:56 2013] [notice] Apache/2.2.22 (Ubuntu)
PHP/5.4.9-4ubuntu2.3 configured -- resuming normal operations
which I understand means the PHP is loading correctly
The only entry I do not understand is
[Sat Sep 07 13:19:00 2013] [error] [client 127.0.0.1] Premature end of
script headers: index.php
I've done searches but most of the articles I've found are no help.
Is there anything else I can do to try to debug the error or does anybody have any ideas as to why this error is happening?
Thanks in advance,
Is error reporting on in php?
try adding:
<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
on the first line of the script after
First of all thanks for VIVEK-MDU for the suggestions and changes to my post. I must admit that I thought the lists were done automatically (I never got into markdown (just seen I missed the space before the minus sign on the list items)).
Answer?
Unfortunately I cannot help anybody who lands at this page with a similar problem.
I also develop on my laptop which has a similar setup. after copying:
/etc/apache2/
/etc/hosts
/var/www - the correct permissions for my system are my-user (not root or www-data)
The system now works as expected. Again: sorry I can't help anybody else but thanks to everyone who looked and the people that helped.
John
I have an strange problem with Zend Cacke (File Backend) running on linux with apache and php 5.2
The files are stored in /myspace/tmp1
Directory has the persmission:
drwxrwxrwx 2 nobody nogroup 8192 2010-09-20 13:35 tmp1
The created temp file has the following permissions:
-rw------- 1 nobody nogroup 317 2010-09-20 13:40 content---a51607ba255692370eae1155c7f45856
If if i do:
$cache->clean(); inside my script, than the method returns true, but the file is not removed (no error in php error log).
On my local development machine running under win xp everything works fine. I think it is some kind of permission problem? The Apache is running as "nobody"
Any suggestions are welcome!
I think you need to use Zend_Cache::CLEANING_MODE_ALL as by default it cleans only outdated AFAIK.