I want to download a file using php. Everything is working fine on windows, but when I try to run the same php code on my ubuntu 12.04 just an empty file gets downloaded without any content. When I try to run the following code:
<?php
$filename = '/root/my_folder/filename.pdf';
if(file_exists($filename))
$f = fopen( '/root/my_folder/filename.pdf', 'r') or exit('unable to open file');
else
echo 'file does not exists';
?>
It always display the 'file does not exists'. Is the issue with setting path to my folder ?
Can anyone help me with this. I'm new in Ubuntu. Thanks
your apache user does not hae the permission to access /root/myfolder/filename.pdf . You will have to either add apache user to the group that is accessing /root/myfolder or change the ownership of filename.pdf or change the permissions on /root/myfolder
Related
After deployed my Laravel code on Ubuntu server I have following function returning empty string:
$package = $request->file('file');
dd($package->getPathname());
while locally (Windows) it is working and on other hosting (Ubuntu too) it is working too.
What could be the reason for that?
Thank you!
This is most likely due to the web user that the php is running on being denied the access to the temp directory used to store the uploaded files.
You can check it by running the following snippet (that i took directly from the php manual) on the directory that you are uploading your files to:
<?php
$filename = 'test.txt';
if (is_writable($filename)) {
echo 'The file is writable';
} else {
echo 'The file is not writable';
}
?>
Check this code:
<?php
$url = 'http://www.example.com/downloads/count.txt';
$hit_count = #file_get_contents($url);
$hit_count++;
#file_put_contents($url, $hit_count);
header('Location: wmwc.zip');
?>
#file_get_contents is working fine and the header location change to the downloaded file also works, but either the hit_count increase or #file_put_contents isn't working, because the number with the file doesnt increase by 1. I've set the file permission to 777, but when I try to set the directory permission to 777 also I get a 500 internal server error saying "The server encountered an unexpected condition which prevented it from fulfilling the request."
You can't write a remote file via http.(If you could do that, every one else could change that file also.)
You need to use the local path.
try changing directory properties
chown www-data:www-data <dirname>
and/or write as follows, if you host on linux
<?php
$var ="hi";
shell_exec('echo "'.$var.'">>log.txt');
?>
So here's the story, im not very experienced with php, and recently moved to a new host and my website worked prefectly on the old host but on the new host there are errors with the code.
The error message says :
Warning: copy() [function.copy]: Unable to access http://i.imgur.com/USlH6p2.jpg in (directory)
Heres the code where it says there is an error
function upload_image_remote($image, $name) {
$upload_dir = APP_PATH . '/image.uploads';
//check for directory rights
if(!is_writable($upload_dir)) {
echo do_error(_('Folder image.uploads is not writeable'));
exit;
}
//check if there's a directory for today uploads
$today = date("d-m-Y");
if(!is_dir($upload_dir .'/' . $today)) {
if(!mkdir($upload_dir .'/' . $today, 0777)) {
echo do_error(_(sprintf('Folder <strong>image.uploads/%s</strong> could not be created. Please check permissions to be 0777.', $today)));
exit;
}
}
$upload_path = $upload_dir .'/' . $today;
(--> this is where) return copy($image, $upload_path .'/'. $name);
}
I think it may be a permissions problem since it worked perfectly on (old host) 000webhost, anyone have any ideas on what can be wrong with the code ?
Thanks
My guess would be that the copy function is trying to access the remote file and cannot due to the PHP settings.
I think most hosting companies, for security reasons, will have allow_url_fopen = 0. This means that you will not be able to read from the remote location (http://www.site.com/foo.gif). However, you will be able to read from the local file system.
From the PHP documentation:
This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol, some extensions like zlib may register additional wrappers.
To check this, view the current PHP settings on the server by creating a file with the following contents in your web root. Your looking for the allow_url_fopen setting.
<?php
echo phpinfo();
?>
Give folder permission 0755 Set correct path of temp folder for file
system.
So, I have this simple little php script. It runs and compiles fine and works the way I want it to on the machine that I coded it. I'm running it on a personal home web-server running Debian 6.0.6, 32bit. It's apache with php. And I know for a fact that php is working on the server.
<?php
$hitsfile = "hits.txt"; #name of file
$filehandle = fopen($hitsfile, 'r') or die ("Couldn't read file."); #Opens file, 'hitsfile' to be read.
$hits = fread($filehandle, 5); #reads file to the introduced variable, 'hits'
fclose($filehandle); #closes file
$hits++; #increments the variable that it read.
$filehandle = fopen($hitsfile, 'w') or die ("Couldn't write to file."); #opens file to be read.
fwrite($filehandle, $hits); #writes the hits variable to file.
fclose($filehandle); #closes file.
echo $hits; #outputs the hits variable.
?>
When I access the file from the server, via a web browser, I get the "Couldn't write to file." error. So then, it's opening the file properly, and reading it. And when it opens it to write, it fails. I'm assuming this is some sort of problem with permissions or something. I'm sort of at a loss as to how to solve the issue. Any ideas? Assistance would be greatly appreciated! I've googled for a couple days now, and I can't solve the issue. I'm a php 'noob' and I'm very new to running a linux-based web-server, but hey, you gotta learn somehow. :*l
tried to check the permissions to the file? The Linux file system have a very strict permission system. Write on terminal:
ls -la /path/to/my/file.txt
This would give you your permissions on the left column. Please read this article to be sure, and check if Apache have the "write" permissions to the file. If not, use the chmod command to give Apache access to the file (or the chown command, to change the owner of this file to apache, if the owner of this file have writing permissions).
I have a form, which uploads an image.
I try to get it by $_FILES:
$filename = $_FILES['screenshot']['name'];
$source = $_FILES['screenshot']['tmp_name']."/".$filename;
$target = GL_UPLOADPATH.$filename;
echo "TEST0";
if (move_uploaded_file($source, $target)) {
//connect to DB and so on, what I need
echo "TEST1";
}
So I get echoed TEST0 but don't get echoed TEST1.
If I echo every variable - it's normal. I see my $target - it's something like /tmp/phpoLqYdj/test2.jpg
So, I think PHP can't move_uploaded_file because it can't find /tmp/phpoLqYdj/test2.jpg
But where is /tmp/phpoLqYdj/? I am testing on localhost. My document root is /var/www/.
PHP has default settings in php.ini (upload_tmp_dir is commented in php.ini).
In my /tmp/ folder (in system) I don't have such folder like php***. In /var/tmp/ either.
(Ubuntu 10.10, LAMP was installed by "tasksel")
When you uploads files via PHP, it stores them in as a tmp file that's not named anything related to the filename. Appending $filename to $_FILES['screenshot']['tmp_name'] is the incorrect way to handle it... $_FILES['screenshot']['tmp_name'] IS the file.
Also, the tmp file is removed at the end of the request, so you'll never have a chance to actually see it in the file manager. Either you move it in the same request, or it's gone. It's all done in the name of security.
Anyway, just use this instead and you'll be good.
$filename = $_FILES['screenshot']['name'];
$source = $_FILES['screenshot']['tmp_name'];
$target = GL_UPLOADPATH.$filename;
echo "TEST0";
if (move_uploaded_file($source, $target)) {
//connect to DB and so on, what I need
echo "TEST1";
}
I had the exact same problem. What I did to fix it was change the permissions of folder that you are uploading to, to read and write for all.