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
Related
Server version: Apache/2.4.34 (Unix)
NOTE: This is not a Plesk or control panel questions. This is a custom PHP application hosted on a Rackspace dedicated server with no control panel.
I'm trying to utilize an existing SSL certificate for several sub-directories of a domain, but the architecture for the domain separates out two directories for non-secure/secure:
httpdocs
httpsdocs
I copied everything from httpdocs to httpsdocs and also forced traffic to https using .htaccess. Everything worked great until I tried the PHP file upload functionality.
Here's the bit of code that is failing from the secure side:
$path = "uploaded_files/".$row_query[0].'/'.$file_name;
copy($temp_file, $path);
In doing some debugging, I found that the temp file gets created:
/tmp/phpanKT4N
but the error I see in the logs is:
copy(uploaded_files/New Sub Folder/30052_testing.txt): failed to open stream: Permission denied in /var/www/vhosts/.com/httpsdocs/demo/resource/add_resource.php on line 108
I tried changing copy() to move_uploaded_file() but here's the error for that:
PHP Warning: move_uploaded_file(uploaded_files/test/30054_testing.txt): failed to open stream: No such file or directory in /var/www/vhosts/<thedomain>.com/httpsdocs/demo/resource/add_resource.php on line 111
PHP Warning: move_uploaded_file(): Unable to move '/tmp/phpOC9YEF' to 'uploaded_files/test/30054_testing.txt' in /var/www/vhosts/<thedomain>.com/httpsdocs/demo/resource/add_resource.php on line 111
I searched stack and saw that ownership must match, but the permissions appear to be the same for httpdocs and httpsdocs.
The /tmp folder is owned by root:root and like I said this works perfectly from the non-secure folder. The non-secure and secure upload folders are identical:
httpdocs:
drwxrwxr-x+ 8 theuser apache 4096 Sep 22 2015 uploaded_files
httpsdocs:
drwxrwxr-x+ 8 theuser apache 4096 Sep 22 2015 uploaded_files
Is this a configuration, permissions issue, or what?
Figured this out... Ran the following:
First find apache's user:
egrep -i '^user|^group' /etc/httpd/conf/httpd.conf
Result:
User apache
Group apache
Then ran this and it solved all the PHP file upload issues in httpsdocs:
chown -R apache:apache /var/www/vhosts/<thedomain>.com/httpsdocs/
chmod -R g+rw /var/www/vhosts/<thedomain>.com/httpsdocs/
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'm getting an Invalid argument warning when moving a file from a local disk to an NFS mounted disk. The file is moved successfully despite the error message:
Warning: rename(/tmp/image.jpg,/mnt/remote.server-disk1/image.jpg): Invalid argument
The mounted disk:
$ df
remote.server:/disk1 917G 269M 871G 1% /mnt/remote.server-disk1
The exported disk on the remote server:
$ cat /etc/exports
/disk1 remote.server(rw,sync,root_squash,secure,crossmnt,anonuid=504,anongid=504)
The file on the local disk before rename():
$ stat /tmp/image.jpg
File: `image.jpg'
Size: 2105 Blocks: 8 IO Block: 4096 regular file
Device: 803h/2051d Inode: 33556339 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 501/ apache) Gid: ( 501/ apache)
...
The file on the remote disk after rename():
$ stat /disk1/image.jpg
File: `image.jpg'
Size: 2105 Blocks: 8 IO Block: 4096 regular file
Device: 821h/2081d Inode: 34603214 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 501/ apache) Gid: ( 501/ apache)
...
Any ideas?
Thanks
In Unix you can't rename or move between filesystems, Instead you must copy the file from one source location to the destination location, then delete the source. This will explain the error message you're getting. However, it seems unclear as why it still does the move. This could be related to permissions or the NFS mounted disk is locally cached.
Maybe a bit late, but i think the answer is probably because of permissions linked to the target file system.
We had the same issues, and a strace give us the proper diagnostic:
strace php -r "rename('SOURCE_FILE', 'DST_FILE');";
...
chown("SOURCE_FILE", 0, 0) = -1 EINVAL (Invalid argument)
write(2, "PHP Warning: rename(SOURCE_FILE"..., 192PHP Warning: rename(SOURCE_FILE): Invalid argument in Command line code on line 1
) = 192
write(1, "bool(false)\n", 12bool(false)
In our case, the target file system was an NFS with version 4, and idmap was enabled.
Even a simple
chown $(whoami) $DST_FILE
wasn't working.
It's the default behavior (under debian at least) to have idmap enabled with nfs-common utils.
So even if you fix it by using a copy + unlink (which is the best approach by the way), it may still hide an issue in your underlying file system.
(to disable idmap : https://forums.aws.amazon.com/thread.jspa?threadID=235501)
Maybe it's because you doing this with no quotes
rename(/tmp/image.jpg,/mnt/remote.server-disk1/image.jpg);
try adding quotes
rename('/tmp/image.jpg', '/mnt/remote.server-disk1/image.jpg');
I couldn't resolve this, but copy() and then unlink() worked without error.
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.
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.