I have the following script which works fine locally:
<?php
//Report all errors
error_reporting(E_ALL);
if ($handle = opendir('instance/system/application/images/dir/testimages/')){
while (false !== ($fileName = readdir($handle))){
$newName = str_replace(" ", "_", $fileName);
rename($fileName, $newName);
}
echo "All files have been renamed";
closedir($handle);
}
?>
However when run on the web server I get the following error:
Warning: rename(.,.) [function.rename]: Permission denied in C:\inetpub\vhosts\domain.com\httpdocs\rename.php on line 10
Any idea how I can resolve this?
Cheers
Note:
I am using IIS7 and a windows server.
Couple of things:
In windows, go to the directory where you want to rename files, right click, and look at the permissions for both the folder and the files within. Whatever the process is running the web server needs to have permissions to modify those files, or create new files in the directory.
Secondly, and more subtly - I think the root cause is a bug. In the PHP manual, there's a comment suggesting that rename will put the file in the current working directory unless you specify your full directory path in the "to" argument.
So, if you are trying to rename "c:\instance/system/application/images/dir/testimages/banana pic.jpg" to banana_pic.jpg, your current code will write that to the current working directory - probably the location of php.exe - that will fail.
I'd try to specify the folder in which you want the renamed file to be placed, and see if that works...
Set permission to files You want to rename to 777.
In file manager, like, filezilla, right click on file and set permissions.
Or just google: set permissions to files on server.
You can try through PHP too: http://php.net/manual/en/function.chmod.php
In order to rename or chmod a file, you need to have access to do that. This means that the file should be either owned by the webserver process, or should be with appropriate mods that allow it to be changed by anyone (like 777)
NOTE: This comment is not appropriate for a windows server. I didn't realise this when I commented. This is appropriate for linux, not windows.
You do not have permission to edit the image so need to chmod() the file:
The chmod() function changed the permissions of the file so you can rename it. The "777" means that anyone can (for a millisecond) change, read and execute the file. Then you write it back to "644", so that anyone can read, but only you can change the file. This second step is for security. You don't want files on your server editable and executable by everyone.
<?php
//Report all errors
error_reporting(E_ALL);
if ($handle = opendir('instance/system/application/images/dir/testimages/')){
while (false !== ($fileName = readdir($handle))){
$newName = str_replace(" ", "_", $fileName);
chmod($fileName, 777);
rename($fileName, $newName);
chmod($newName, 644);
}
echo "All files have been renamed";
closedir($handle);
}
?>
Related
i'm writing a simple php script which made some stuffs every hour and write a log file.
The issue is cronjob doesnt write to log file, is it a permission issue? is it a path issue?
I have an hosting service by siteground. Script file has permission to write, read and execute.
I've already try to set a cronjob which just send me an email without write a file and it's running.Thanks
This is my code:
//
//some stuffs here
//
$file='www.domainname.com/logfile.csv';
$handle = fopen ($file, "w");
fwrite($handle, "hello, i done some stuffs");
fclose($handle);
You should use the absolute or relative path to the file on the file system.
example: -
$handle = fopen( $_SERVER['DOCUMENT_ROOT'] . '/logfile.csv' );
Generally having a writable file in the web servers directory is a bad idea. If your program can write to the file, then the web server can write to the file too. That opens the possibility for someone to overwrite the file through the web server. At best you lose data from being over written. At worst it allows remote code execution.
It would be better to put the writable files outside the web server directory.
<Parent directory>
<Place for writable files>
<Web server directory>
In your programs run from the webserver you just need to specify the path to the files.
Relative Path
$relitivePath = '/../writeDir';
$handle = fopen( $_SERVER['DOCUMENT_ROOT'] . $relitivePath . '/logfile.csv' );
Full Path
$fullPath = '/somedir/ParentDir/writeDir'
$handle = fopen( $fullPath . '/logfile.csv' );
Running from cron a bit different than running it from shell. The environment you are use to is not set up like yo have when sshing in. Your going to have to list the full path or set up the environment.
$fullPath = '/somedir/ParentDir/writeDir'
$handle = fopen( $fullPath . '/logfile.csv' );
To get your full path
When ssh'ed in:
cd to the directory where the file located.
Do a pwd this will print the current working directory path.
Use that path in like above.
In the program it is a good idea to turn error reporting on.
You also don't want to have the program you call from cron in the web directory.
I see your service provider has a way to email any output from cron. That will help with error reporting.
I am using PHP to move an image to a specific directory. It fails if I have /tmp/ with permissions 755 but it doesn't fail if I have it with 777. Since 777 is not secure, is there any other method to do this?
My PHP code is this:
$dir = '/var/www/spectrom.benrosen.org/uploadedimages/';
$file = basename($_FILES['uploadimage']['name']);
$uploadfile = $dir . randomize() . $file;
if (move_uploaded_file($_FILES['uploadimage']['tmp_name'], $uploadfile)) {
exit('{"result": "successful"}');
} else {
exit('{"result": "could not upload image."}');
}
I wouldn't worry about the /tmp folder. Any user should be able to write to it. You shouldn't leave anything sensitive in the tmp folder.
This will also fail depending on the settings of your uploadimages folder. Make the owner of that folder the PHP process. That is system dependent. If running apache it may be controllable through .htaccess but definitely httpd.conf
Garr is right about the /tmp folder. Any way, if you are worried about the folder security please check this http://shapeshed.com/securing_upload_folders_in_php_on_unix_servers/ it explains how to convert the upload folder permission to 755.
I'm trying to upload a file (msword/doc) to a Apache server folder via an HTML form. It works when I test it locally (I'm testing it via MAMP), but when I upload it to a remote server (such as GoDaddy), it doesn't work. It shows "There was a problem with the file upload".
Below is the snippet of code that processes the file upload. I can't figure out what is wrong with my conditional.
// Move the file to the target upload folder
$target = FILE_UPLOADPATH . basename($new_file);
if (move_uploaded_file($_FILES['new_file']['tmp_name'], $target))
{
// The new file move was successful, now make sure any old file is deleted
if (!empty($old_file) && ($old_file != $new_file))
{
#unlink(FILE_UPLOADPATH . $old_file);
}
}
else
{
// The new file move failed, so delete the temporary file and set the error flag
#unlink($_FILES['new_file']['tmp_name']);
echo 'There was a problem with the file upload.' . PHP_EOL;
}
Are you sure that the folder you are uploading to has permission for files to be written to it? If not, use chmod 0777 and test with that.
Does your destination folder have proper permissions? http://en.wikipedia.org/wiki/Chmod The directory write to typically needs 775: What are the proper permissions for an upload folder with PHP/Apache?
Also, do you want users to have direct access to the file? If not you should consider writing the file to a folder that is above your web root directory.
If $_FILES['new_file']['error'] == 0 then the upload isn't the problem, but the call to move_uploaded_file() is. You probably have incorrect permissions on the directory you're trying to move the file to.
For me, I happened to be testing locally with a file under php's upload_max_filesize while testing remotely with a file over upload_max_filesize. See https://stackoverflow.com/a/30359278/3325776 for more info.
I am using the move_uploaded_file function to upload files. The files get moved into the right directory and I see its physical existence, but I can't open them. I get "Access Denied" error. I view the properties of the file and I found that it doesn't have an owner.
By the way, I am running IIS on Windows 2008.
I check the permissions, everything is set up correctly. The user that is running the web service has full admin rights.
Additionally, I replaced the move_uploaded_file function with copy(), and I was able to access the file. It also had the user that is running the server as its owner.
What on earth could possibly be wrong?
Thanks I appreciate your help.
UPDATE:
After the file is moved I tried to set permissions using chmod($filename,0655) but that didn't work either.
UPDATE 2 (solution):
Alright guys, I figured it out.
The system administrator didn't set the upload_tmp_dir.It worked once we added a path.
Source code:
// Check if file was uploaded
if(isset($_FILES['formname']) && $_FILES['formname']['size'] > 8){
$displayName = $_FILES['formname']['name'];
$displayName = unixfilename(basename($displayName));
$tempName = $_FILES['formname']['tmp_name'];
$filename = $_FILES['formname']['name'];
$fileType = substr($filename, strrpos($filename,".")+1);
$filename = substr($filename,0,strrpos($filename,".")) . date("_Ymd_His") . ".$fileType"; // Add unique identifier
$filename = unixfilename(basename($filename));
$destinationPath = "xx\yy\zz\\";
// Check if the file is of a valid type
if($fileType == "txt"){
// Check if file exists in processor folder
if(!file_exists($destinationPath.$filename)){
if(move_uploaded_file($tempName,$destinationPath.$filename)){
if(file_exists($destinationPath.$filename)){
// success
check who is the user who do the upload actually
echo exec('whoami');
In addition to having upload_tmp_dir set in your php.ini file, ensure that the directory you set is writable by PHP.
If you're using the PHP Manager in IIS, it defaults the upload_tmp_dir to C:\Windows\Temp which was not writable by the PHP process by default for me.
I've a problem with jQuery uploadify script and I didn't found any solution.
I've integrated this script on my project and everything is working fine on a Windows server(localhost) but when I try to run it on an UNIX server and I/O error is risen.
This only happens when I try to upload a file that already exists on uploading folder. On Windows the file is overwritten but a UNIX I get and I/O error.
Please if you have any solutions I'll be very grateful.
Here is the server side code which I think is the problem(PHP code):
if (!empty($_FILES)) {
$tempFile = $_FILES['Filedata']['tmp_name'];
$targetPath = $_SERVER['DOCUMENT_ROOT'].$_REQUEST['folder'].'/';
$targetFile = str_replace('//', '/', $targetPath).$_FILES['Filedata']['name'];
if (file_exists($targetFile)) unlink($targetFile);
copy($tempFile, $targetFile);
echo "1";
}
First few things to check:
Which user owns the file that exists?
Which user owns the directory that the file is in?
Which user is running your PHP script?
What are the permissions on the file itself?
What are the permissions on the directory that the file is in?
The reason I ask these questions is because it may be a simple permissions problem. The user running the unlink and file create of the target file will need write access to the directory. It's possible that the user that's running the script is not the one that owns the directory or file, in which case you may have to open up the permissions a bit.
Of course, that's just conjecture on my part but that's the first thing I'd be looking for.
First of all, you should use move_uploaded_file instead of a copy.
But most likely your problem is due to a permissions problem. Can you upload any file to the folder? Have you checked that the files already in the folder (those you want to overwrite) have the same permissions as a newly uploaded one? My guess would be that you copied the files to the folder using (S)FTP and that they have a different owner/permissions so you can't overwrite them.
In addition to the possible permissions issues mentioned by paxdiablo and wimvds, also check the case of your filename & path. Unlike windows, unix filesystems are case-sensitive.