I am sub-contracted through a large data center that uses shared servers and cPanel. I create websites for their hosting clients.
Their configuration is off. When I upload files to the server through cPanel directories are given 775 permissions and PHP files are given 664 permissions.
Every time I upload an application I have to recursively change the file permissions of the PHP files from 664 to 644 or no PHP will execute and results in a 500 error.
This is particularly painful because as a sub-contractor I have to ask for temporary shell access every time I need to do this.
Obviously the problem is that the PHP files are being executed by the group, and 664 permissions do not allow execution.
I'm not too familiar with cPanel, and I'm unsure what is causing this problem. Is this a problem with the server, or with cPanel? How can I change the default upload permissions for cPanel?
for cpanel, both owner and group have to be the username of the cPanel user.
In a typical cPanel configuration, the root directory for the accounts is home. Depending on the size of the server, it could be home2/ or home3, etc.
chown -R username:username /home/username/public_html/path_to_files
Related
I am working on a WordPress website from 2 months and I have uploaded many images before but I am getting an error when uploading image and I am facing this issue after new year :- The uploaded file could not be moved to wp-content/uploads/2015/01.
there is Screenshot below:-
This article explains and resolves the issue very well: http://2surge.com/how-to-fix-the-uploaded-file-could-not-be-moved-to-wp-content-error-message
The basic premise is that the identity of the process running your httpd / apache / web server thread must have write access to your upload directory.
To resolve the issue:
Check which account your webserver is running under
Update: On Unix use...
ps aux | egrep '(apache|httpd)'
... this will show a list of processes for the web server along with the identity of the process under which its running e.g."nobody"
nobody 8718 0.1 0.4 1332864 17180 ? Sl 17:11 0:06 /usr/local/apache/bin/httpd -k start -DSSL
Update the permission of the upload directory to allow that account to write to it.
Update: On Unix, you can use...
chown -R nobody /<path to upload directory>/wp-content/upload/
You can also amend permissions for this account (at the rquired location) to ensure it has write permissions using chmod or filezilla and cascade the changes to the directories as necessary.
Check out the linked article for a detailed breakdown. Hope that helps! :)
This works for me.
$ sudo chown -R _www uploads/
$ sudo chmod -R g+w uploads/
I am assuming you are in the wp-content directory.
You just need to give permission to PHP to write in the uploads folder, this worked for me:
sudo chown -R www-data <path>/wp-content/uploads
I have searched and found that the problem is from server provider.
Typically, all files should be owned by your user (ftp) account on your web server, and should be writable by that account. On shared hosts, files should never be owned by the webserver process itself (sometimes this is www, or apache, or nobody user).
Any file that needs write access from WordPress should be owned or group-owned by the user account used by the WordPress (which may be different than the server account). For example, you may have a user account that lets you FTP files back and forth to your server, but your server itself may run using a separate user, in a separate usergroup, such as dhapache or nobody. If WordPress is running as the FTP account, that account needs to have write access, i.e., be the owner of the files, or belong to a group that has write access. In the latter case, that would mean permissions are set more permissively than default (for example, 775 rather than 755 for folders, and 664 instead of 644).
You can see here how to change file permission..
If you're using something with SELinux (like Fedora or CentOS), you'll also need to set SELinux permissions. Assuming that your directory is called uploads (for example)
chcon -R -t httpd_sys_rw_content_t uploads
This will set uploads and everything under it to be uploadable to the web server user
it probably doesn't have the permissions to create
/uploads/2015
Check if that folder exists, if it does, then check
if /uploads/2015/1/ exists.
permissions:
chmod 755 /uploads/2015/1/
chown www-data:www-data /uploads/2015/1/
These folders should have the same permissions as the /uploads/ folder.
Also check the error_log, because it should show you exactly what folder is causing the issue.
This works for me
sudo chown -R www-data html
Assuming current directory is www
Ubuntu 16.04, Apache2
I had this problem as well and found out it was because the hosting account's disk quota was exceeded.
I found that there was an old script that was logging errors and the error log had gotten so big it filled the available quota.
I finally figured it out when I attempted to create a new directory using FTP and the server response was "Disk quota exceeded."
I got this error on a cPanel hosting account, where the disk quota (for the account) was not an issue. After delving into it for a while, I found that cPanel's "Select PHP Version" tool was set to v7.1 but multiple WordPress diagnosis tools were detecting v5.6 was actually running, and they also detected file system issues.
The File Manager tool in cPanel showed all the permissions were correct, and the folders were writeable.
One of the diagnosis tools I used was part of the Wordfence plugin. It was available on the Dashboard menu at Wordfence > Tools > Diagnostics (tab).
I reported the issue to the hosting company, and it appeared to fix itself overnight (the person who responded to my support ticket indicated they didn't fix anything). I think it's likely it was a symptom of a problem that affected multiple hosting accounts, and somebody else within the hosting company probably detected it and fixed it.
In case others encounter a similar issue, I hope this answer helps them spend less time trying to track it down. Once I discovered the incorrect PHP version appeared to be running, I figured it was probably not something I could fix with only cPanel access.
This will happen when you migrate a WP site to a different server.
Problem is the ownership.
Run this in a terminal:
chown -R <site-user-name> /home/<site-directory>/public_html
z
There are multiple reason because of this such error arise.
Main problem is folder permission.
wp-content/upload/
Folder permission must be 775 or 664.
Other solution if the error not get resolved try below
Go to Cpanel and your website folder or by using FTP.
Then you will get wp-config.php {This file available on root folder}
In that do below change
Open the wp-config.php file and add the following code:
define( 'UPLOADS', 'wp-content/uploads' );
before below line
require_once(ABSPATH . 'wp-settings.php');
I hope this will help. It's help me on Plesk Hosting.
This solution is only for those who use the cPanel control panel, and you must test this for other panels like aaPanel, Directadmin and others ...
Be sure to take a snapshot/checkpoint from your server before making changes.
Install the mod_suphp module through Easy Apache.
After installation from the MultiPHP Manager section:
Select suphp from the drop-down menu under the PHP Handler column
And finally, apply the changes.
Test again and if necessary type the following commands:
/usr/local/cpanel/bin/rebuild_phpconf –current
Open you xampp
Click on explore
Double click on folder of your project
Click on "Get Info" in options list
Unlock the locker in the right bottom side by entering your password
Then change permissions to read and write
MOST IMPORTANT POINT, remember to click on the bottom left conner dropdown and select Apply to all
There it will work.
Watch how it is done in this video
Thank me later How to fix xampp permission problem on mac
Changing directory permission to 777 helped me.
I'm trying to upload a file to a virtual machine in Amazon. and i have some questions.
I think i have to give (777) permissions to my server folder to be able to upload my file. if i don't it won't work. is this ok?
is it secure to give those permissions?
You don't need to make the file's permissions 777 in order to be able to write it into a directory. Instead, the directory needs to have permission to be written to by the user.
If you are running apache, the process runs as the user www-data and wherever you are trying to write the file to, must have write permissions by this user. If you are writing to /var/www/my_file_uploads, then try this:
chown -R www-data:www-data /var/www/my_file_uploads
Note that by doing this, you will be preventing others on your home machine from reading the file as well (unless you explicitly permit it).
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 CodeIgniter app running in production on Apache 2.2 with PHP 5.3 on Ubuntu 11.10. I am also running PHP5-APC, if that matters. So the app runs as www-data:www-data per the default Apache2 install.
I am trying to figure out what to set my file permission to. Many threads on SO seem to prefer 755 for directories and 644 for files. There is one directory that must allow files to be uploaded to it.
Currently my deployment script does something like this:
wipe old site
copy new site over
chmod -R 000 on the new site
chmod all directories to 500
chmod all files to 400
chmod 700 on the upload directory
Everything seems to work fine. I can upload files and so on.. so, I don't understand why people suggest 644 for files - I have a config file that has passwords and API keys - why would I want 'others' to have read-access to it?
What am I misunderstanding?
Well, mainly the 644 permission is meant for when you have /var/www/site1.com with different user and group set then www-data, because then the 644 would allow other groups and users to read from that file, but will allow to read and write the owner of the file.
As by default the user that uploads files and runs apache's processes is www-data then I honestly think that if it works for you and you have no issues, it's great because means a little more security.
Update
Just a small security issue, is that www-data has become a very common user and group for http services to run their processes. I would much recommend that each site/app have their own user and group.
*44 and *55 just means that the file/folder is readable by others.
This would be good if say, you uploaded files to the web server but they for some reason were owned by someone else (say your own login account), then apache could still read them and it'd be "no fuss". Or if you needed multiple groups to be able to access the files.
If you know you are uploading the files as the apache user, and apache (or whichever programs run under www-data) are all you need to be able to read/write the files, then *00 is completely fine. It can even be argued that it's a little more secure.
For people who don't know what they're doing on the linux command line, 644 and 755 are about the right mix between "convenient" and "safe" (completely debatable, though), so they are what is recommended for a quick fix.
When doing shared hosting, you have user accounts that upload php files via FTP. So, when user "joe" uploads his .php file, it is owned by "joe" and when Apache needs to read it to execute the script, it cannot. Users are usually in "users" group, so even giving privilege to the group would not be enough. That's why you need to give privilege to everyone, so that user "www-data" can read the file uploaded by "joe".
If you run your own server, than of course, you have full control and none of this matters.
So, basically the question is in the title and a little more detailed scenario:
I have a site's backend written in PHP (on linux server - centos 6) and I actually have only 2 users who have the access to it. They need to be able to upload images via some form. So, I made the simple upload script, but no matter what (or am to ignorant to know :/), the upload only works on folder permissions set to 777, so my question is is this ok, or should I implement some better 'common practice' in this situation?
You don't need the directory permissions at 777. What you need is to be certain the the directory is writable by the web server user, which either means making it owned by the web server user or owned by another user with its group set to the web server user and group-writable permissions.
So if your web server user was www-data for example (other common possibilities include apache, httpd, www):
# Set ownership to the web server user
chown www-data uploads_dir
# and make it writable by the web server user
# could also be 755 (readable by others)
chmod 700 uploads_dir
Or if it must stay owned by your account user (on a shared host for example), set the group to the web server user:
chown youruser:www-data uploads_dir
# and make it group-writable:
chmod 775 uploads_dir
The bottom line is that it is usually not a good idea to assign 777 (world-writable) permissions to a directory. Also, uploads_dir should ideally be placed outside the web server's document root so it isn't available vit HTTP requests.
You can also use something like suphp to run the php scripts as a user, while retaining the ability to have the folder not writeable by any other user or group.
You would need administrative access to your webserver for this, though.
A solution is to use FastCgi.
This make new files and directories owned by the the same user and group.
There is a performance penalty to FastCgi but you get some added security as it restricts php. If you are hosting multiple website with multiple users this could be a good idea.