I am using PHP file_put_contents to generate PDF files inside a directory named invoices.
This was working fine for a long time but stopped working with no changes to the code generating the invoices (I have asked the hosting providers about any changes to the installation but they are no help).
The error I get is "Warning: file_put_contents(test-generate-file/999999.pdf): failed to open stream: Permission denied"
However, this seems to be a file ownership issue rather than a permissions issue because after some testing I have found that:
The error occurs when the invoices folder has ownership cpanelusername:cpanelusername (this is the correct ownership needed for folders and files on the server to be viewed by visitors etc).
Files are successfully generated when the ownership is changed to PHP which has the ownership name nobody (so ownership nobody:cpanelusername works)
But the files that are generated successfully with ownership nobody can't be viewed by visitors.
As a workaround after they are generated I am manually changing their ownership to cpanelusername:cpanelusername so they can be viewed. But this is a pain.
So the question is what is preventing files being generated by PHP when the folder has the correct ownership is in place and how can I fix it?
I have viewed multiple similar questions but they mainly refer to file permissions as opposed to file ownership and have not helped. Also setting permissions of the invoices folder to 777 is not an option due to security being important.
Related
In my code for uploading pdf documents to my web-server, I have used move_uploaded_file.
move_uploaded_file($tmp_source, $destin)
However, this command does not work unless I give 777 access to the uploads folder. I tried making it 775, but it wouldn't work.
I get the following error message
failed to open stream: Permission denied in /srv/http/host1/public_html/internal/upload.php on line 82
By putting the uploads folder above public_html, I can prevent people from accessing them via a browser, but how do I prevent local users from accessing this folder through ssh?
Some answers related to this question had suggested using
ps aux | grep apache
to find out the user to who the upload folder should be given appropriate permissions 0755. This information did not work for me.
However, the correct information was available in phpinfo() under the apache2handler header. It was http.
Among other things, I have restricted file types to pdf, set .htaccess to restrict cgi and also kept the uploads folder outside public_html to prevent access through browser.
I am not aware of further security concerns.
I have a access to the server where many wordpress blogs are hosted. Initially the permission to uploads folder were set to 777(Recursively) but this caused problems to our server and malicious files where uploaded due to which our server is blacklisted.
I have deleted all those PHP files under uploads folder and set the permission to 755.
Now the problem is that the admin users to wordpress blogs/sites unable to upload media files.
Please guide me what I can do so that they can upload files (images or videos).
Can we set something which will ask FTP details when they upload files using wordpress admin. I can create FTP users for this.
Please Guide.
Not sure what type of error you are getting. But you can try this
add this line to
define('UPLOADS', 'wp-content/uploads');
wp-config.php
just before below line
require_once(ABSPATH.’wp-settings.php’);
If the directory doesn’t already exist, WordPress will automatically create it as long as the wp-content folder is writeable.
Hey I just set the Permission to chmod -v 747 uploads and it worked. Atleast better than 777.
But would like to here suggestion if this is risky. If risky then how much. I am new to permissions and server management.
Thanks !
I know this is an old thread but I found it high in the results for an unrelated issue I am having. It seemed by the permission modes being used #vanurag was actually having a user/group permissions issue rather than the permission modes (755 vs 777) issue.
You can find the web server user with var_dump(whoami()) in php, could be something like www-data.
Once know the user name verify that user is either the owner of the folder or is in the group assigned to the folder. You can use the following in Linux console to find current user/group.
ls -l /path/to/wp-content/uploads
Either add the web server user (www-data) as the owner and leave the group as it is or add the user to the group who have permissions.
Use chown (change owner) to set your users to your needs.
I usually add the user to the group rather than change the owner since the owner could be an FTP user and may mess up permissions used else where in your configuration.
usermod -g www-data foobar where foobar is the name of the group who has permissions to the uploads folder.
Here is a decent article on this issue in respect to WordPress uploads folder.
https://www.digitalocean.com/community/questions/proper-permissions-for-web-server-s-directory
My site is on a shared hosting. I've been using FTP and PHP File Manager to upload and delete files. Recently I've found a file I couldn't delete due to permissions, neither in PHPFM nor in FTP. So I've used DirectAdmin (the only option for my plan) to reset all permissions. Then I set all permissions for all files in public_html and subfolders to 777 recursively. I know only that it allows me to do more than any other permission variant.
Now the site is running in a static way, I can open PHP File Manager and it has no permission to upload files. I can upload files in DirectAdmin, however, but that feels unsafe. PHP File Manager reads: 'I/O error'. The directories look like this:
What do 1422 and 1420 mean? What can I do to upload files again? Thank you for the help.
1422 is the user_id the file belongs to and 1420 the group_id it belongs to.
Linux has a permission system, where you can give special permissions to the owner, your group and everyone else.
Permission 777 means everybody can read/write/execute, your group (1420) can read/write/execute and you (user 1422) can read/write/execute the file.
Permissions:
1 is execute file or open directory
2 is write
4 is read
Read/write permission is 2+4=6, read/execute (or open a directory) is 1+4=5
The three numbers represents [owner][group][everybody], so setting a file to 644 means user can read/write and everybody else just read a file.
Edit: The safe thing is to set all files to 644 and directories to 755. Private files should be 600 and executable files 755 (PHP files are NOT executable).
Apache is run as user apache or httpd, which is another user, therefore you must give "everybody" permission to read your PHP files and directories.
Edit2: If you need PHP to upload files, it is really done as user apache/httpd. Therefore you need to give full privileges to "everybody" to open directories and read/write 777. The file permissions should be 666.
What permissions do I need to set up on a directory in order to make it writable by php?
By "writable", I mean copying and creation of new files within that directory automatically by php itself.
I'm testing this on a free host, and the default permissions are 755.
When I try executing a php script, that attempts to create another subfolder of that directory, and copy certain files in it, and it fails.
If I set it up to 777, it works fine, but I assume that doesn't work on all Apache versions because of security reasons?
Also, when creating new files, does php act as the "owner"?
Whatever process that runs the PHP interpreter should should have a user account associated with it. Only that user needs write permission in the directory. So to answer your last question, it's usually www-data or apache that is the owner of that file.
Permission of 777 will work because it allows everyone to read, write and execute that directory but depending on your application this might be a security hole.
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..