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 installed LAMP in my CENTOS and it all looks fine. In my www/html/ folder I placed my script and they all work fine, they can write/read everything. However everytime I create a folder and I put files inside it they cannot write, for example, if I use file_put_contents with PHP it does not work due the permission denied error.
Everytime it happens I need to chmod 777 to that folder and all the files inside. It's a great time loss.
Is there someway I configure the CENTOS so everytime I create a folder or upload a file it automatically will have read/write permission?
If you want new created folder/file to automatically have 777 permission, you must set umask to 000.
Ref: Setting the umask of the Apache user
This one is quit puzzling to me. Please help
I baked a cake using root via ssh and everything went well except for the fact that i could not edit the view CTP files in dreamweaver. kept getting "access denied. Permission problem".
Via ssh and the cpanel i was able to change the permission to 755, 777. Got an error when attempted to change permission via dreamweaver
After changing file permission, I still got the error "access denied. permission problem.."
I then change the USER who owns the file using chown via ssh
I was then able to edit the file without error. I viewed the edited file via cpanel and realized that the changes took place. Bravo!
However, when i viewed the page in the browser, no changes were apparent.
I cleared the cache several times. My tmp folder is chmod 777
What am i missing?
Are you using Scaffolding perhaps? If so, disable it to see what happens.
Double check if these file names are correct too: Controller, View files and View folder.
We moved our Magento installation from one FreeBSD VPS server to another (8.2 to 10.0). After that, we can't see anything in Magentos /var/log/system.log anymore.
We have checked and re checked the permission (777) on /var/log/*
Whe have tried to enable logging in /index.php
We have checked the database => dev/log/active = 1
Whe have tried to change owner of system.log and exception.log
Where afraid something might be missing in PHP, maybe som extension? Or could it be permission on the local servers /var/log directory?
How can we produce an error, that should be logged to Magentos /var/log ?
make sure you root magento directory is writable and make sure apache user has permission to write file
Did you try to delete the old logs?
We had that problem - just renamed file and everything went okay.
I am building a Fedora server (on VirtualBox right now). It is running Fedora 15.
I want my PHP script to be able to edit the contents of a file in the same folder it is in.
The PHP script and the file are in /home/user/public_html/
But, when I call "file_put_contents("./theFile.txt")" I get an error saying that it cannot open the stream, permission denied.
So, I have:
- Made the file permissions 0777.
- Made the folder permissions 0777.
- Added the "apache" user to the group "wheel".
- Changed the user folder permissions to 0771.
- Changed the owner of the public_html folder and the text file to "apache:apache".
I am at my wits end and I have idea what to do next. Suggestions?
SELinux is preventing you from writing out the file. See the httpd_selinux(8) man page for ways to work with/around it.