may i know what permission do i need to add, to allow test.php to able to write file into macos filesystem
PHP Error: <br />
<b>Warning</b>: file_put_contents(20090915203127.jpg) [<a href='function.file-put-contents'>function.file-put-contents</a>]: failed to open stream: Permission denied in <b>/Library/WebServer/Documents/testphp/test.php</b> on line <b>8</b><br />
ERROR: Failed to write data to 20090915203127.jpg, check permissions
this is the error i get on leopard, i already chmod ugo+x for test.php
It's not the file that needs permissions, it's the process running PHP. Assuming you're using (Snow) Leopard in it's default state, you'll need to give the _www user write permissions to the given directory, or give the world write access (a less savoury idea). Both of these can be accomplished with a combination of chown and chmod.
You need to make sure the user the script is running under is allowed to write to the file trying to write to (i.e. 20090915203127.jpg, not the PHP script). If 20090915203127.jpg does not exist, you'll need to make sure the directory that file's going to is writable (by default this will be the present working directory).
You may need to read about chmod.
As far as I know you need root rights to be able to write directly to /Library. Is it absolutely necessary to write to this directory?
If you just write files to your own account, under /Users/accountname it should work (although that depends on the user who is executing the php script).
You need to make the target file / directory writable to the web server. test.php is not into that...
Related
The php script is unable to create file owing to denial of permissions.
PHP Script:
<?
echo exec('whoami');
file_put_contents('/var/www/html/sample.txt','Some random Text');
?>
Output :
apache
**Warning**: file_put_contents(/var/www/html/test/samds.txt): failed to open stream: Permission denied in **/var/www/html/index.php** on line **3**
The directory permissions are all 777
I have had same issue and i misplaced some configuration.Firstly remeber that the user who created the php file can read the file and if the user who created php file is different than the apache user in your case it is apache in that case you will get this exception if you try to write from different users.So what you have to do is simply,and i would suggest you to revoke the 777 permissions as i do not like idea of your files being publicity available on read and write to the world,so get it back to 755 and do the next on the command line of your server.
cd /var/www
change the user of the HTML only as we need it to be writable only,so do not touch the var and www,so basically as soon as you have navigated to he www directory you are going to change the HTML directory owner to the one who is currently running the apache server,and you got that info already,in your case it is apache so we are going to do the next,
chown apache:apache html
At this stage the html file owner will be apache so you will be able to write onto it.Anyway and meanwhile i would strongly suggest you to create separate directory inside html lets say testDir and try there,i would not suggest to change the root folder permissions,i had bad experience with them.Anyway i hope it will help as i suffer more then hour and just now got the right way to do it.This got my issue fixed,hope it will fix your's too.!
test.php opens test.txt and writes to it. It works fine on one hosting server.
After migrating the code to another host, test.php now can't write out test.txt. The error shows:
Warning: fopen(/home/username/public_html/test.txt)
[function.fopen]: failed to open stream: Permission denied
It will only work when the test.txt file is set to 777. On the original host, test.txt was set to 755.
What am I missing to give permission for test.php to write to the file without 777 on this new host?
Also, file upload PHP scripts aren't working either.
It is not just the permission that is important, but also who owns the files. 755 is enough if the folder/file is owned by the same user that is used for running the web server.
Writing directly to the public_html directory is a huge security risk. I suggest creating a subdirectory (probably best outside the public_html) folder and give it the appropriate permissions / ownership.
It is safer to have the folder owned by the user that runs apache (or whichever web server is being used) - usually something like apache or www-data instead of giving world write permissions.
I have written a PHP script for file uploading and for testing I gave my upload directory 777 permissions. The script works fine.
Now I want to remove execute permissions for obvious reasons, but once I do that, I get the following error:
move_uploaded_file([filepath]) [function.move-uploaded-file]: failed to open stream: Permission denied
Just taking the permissions down from 777 to 776 causes this error to appear when I try to upload a file. I don't understand why having execute permissions should have anything to do with this - can someone PLEASE shed some light?
Thank you!
A directory must have execute permission to be accessible in Unix & Linux.
Quoting from here:
On a directory, the execute permission (also called the "search bit")
allows you to access files in the directory and enter it, with the cd
command, for example. However, note that although the execute bit lets
you enter the directory, you're not allowed to list its contents,
unless you also have the read permissions to that directory.
I agree with lserni that the fact that revoking execute permission on the directory for O (the third digit) causes the problem is worrisome as it indicates that the webserver is accessing the directory neither as owner nor as member of the group. You should fix that.
Just taking the permissions down from 777 to 776 causes this error to appear
This shouldn't happen. You ought to be able to run with 770 permissions, i.e., the directory should be owned by the Website user ID, with the group of web server.
This way the owner and the webserver are both able to manipulate the directory and the data. Ideally the Web server serving your website ought to assume the same user ID as the website owner, and that way you can keep the directory mode 700 and have it read-writeable and listable only by you.
If the last digit of the permissions is biting you, it means that the server is running with permissions for "everyone", which may be okay for a development site but isn't too good on a shared site (imagine your passwords being readable by any other website owner in the machine).
However, if you're running on a test machine, the 777 permissions are okay. Directory executable bit does not mean executable (a directory can't be executed anyway) but merely 'listable'. Without that bit, you can create and delete files but you can't know whether they're really there, and move_uploaded_files is objecting to this situation.
There are other solutions (e.g. chrooting each virtualhost in Apache); see also What are best practices for permissions on Apache-writable directories?
for removing the execute permissions you need to execute following commands..
chown -R nobody upload_directory
chmod -R 755 upload_directory
The first command changes the owner of your upload_directory and files under it to 'nobody' which is what php operates under. The second changes the upload_directory and files to only allow user access to writing. -R is for Recursive..
I have a PHP script to copy all files in a directory i have change my server now its not copying index.php file all other files copy successfully and throw bellow warnings.
Warning: ftp_get(tmp/readme.txt): failed to open stream: Permission denied in /var/www/vhosts/Site.com/httpdocs/includes/ftp.class.php on line 123
Warning: ftp_get(): Error opening tmp/readme.txt in /var/www/vhosts/Site.com/httpdocs/includes/ftp.class.php on line 123
Warning: fopen(tmp/readme.txt): failed to open stream: Permission denied in /var/www/vhosts/Site.com/httpdocs/includes/clone.php on line 196
Seems like a permission issue on the new server. Double check the server directory you're accessing to make sure, you and apache have the appropriate permissions.
Like the error message says: Permission denied, in other words your script does not have permission to access the file tmp/readme.txt. Check that the user your PHP script is using has read access to the file/folder. The way to check that depends on what your server setup is so can't give more unless you provide more info about what your server is running.
Welcome to the unix world. It is a permission problem. If you have rights, you can fix it with the command chmod in the server.
$ ssh username#server
$ chmod PERMISSIONS /path/to/filr
check the man page of chmod to understand the permissions. probably you do something like this : +w
It seems this permission issue, not in the new server but in the old server.
Please check owner:group of the index.php file in old server, so that your script can access and manipulate the origin file.
One more thing. Did you run the ftp transfer script, in the browser or in the command line?
This is very important, because one can run the script with APACHE user (www-data) and the other method run the script with your system user.
im running on windows xp and i am an administrator, im using the latest xampp bundle available from their site and i receive these kinds of errors when i use file manipulation functions on php...
Warning: chmod() [function.chmod]: Permission denied in...
Warning: opendir(/feeds) [function.opendir]: failed to open dir: Permission denied in
do i need to set any environment variables for apache before i can use these functions?
but i think the problem lies only on my folder access permissions, but if so, how do i set a folder's accessibility properties on windows?
Does your php worker process have the necessary permissions?
Make sure whatever user the process is running as has proper permissions for the directory it is puking on.
right click on the folder, permissions...
it appears that my script referred to an inexistent directory as i just specified $dir='/feeds';it works fine on my machine in our office but i wonder why with the same configurations here on my pc at home it doesnt
as reference for other people who might have the same problem in the future my answer would be
check and make sure you are pointing your script to the right file :)
You can try setting the umask as well before the chmod like so;
$old_mask = umask(0);
chmod('/path/to/file', 0755);
umask($old_mask);
More information on umask can be found at PHP's Manual