I've moved my wordpress installation from a managed VPS to a new centos server.
Now I've a problem with writing to files directly from the wordpress admin panel.
Folders/files are set with 755/644. User owner is "wwwuser", group is "apache" (I use this one to access to the documentroot via ftp).
I think that the problem is that in /etc/httpd/conf/http.conf I've user and group setted both to "apache", in fact everything works if I change permissions to 775/664, which should mean that when the group owner is setted to apache everything work, right?
So my question is, should I change all permissions to 775 or there's another solution, which doesn't lead to security issues? Is it safe to make all folders and files 775 and 664? What if I change "apache" to "wwwuser" from /etc/httpd/conf/http.conf?
Edit: is it possible that the problem is that in phpinfo, environment pwd is set to /home/wwwuser/test and not to /home/wwwuser/?
I would advise to not change the user Apache is running under (to not edit the Apache config file) but to set apache as the owner of the files.
chown -R apache /path/to/your/app/files
I think it's the easiest solution. If you choose to change the permissions, you shouldn't have to change the permissions for everyone (other): you could change to 774 but I don't see why 775.
By default Apache is running under the apache user on CentOS.
This is a very common problem you are facing right now. Some times files/directories created/uploaded with FTP may have been assign a different users/usergroup. As #Céline Aussourd stated, if you have installed plugin from WordPress then all files and directories will get the default user/usergroup.
Now easiest way to identify which user should be assigned to your files is create a single test file using CPanel file manager called "test.php" and access it from web if it is working then check its user/usergroup and change all your setup files to that user/usergroup all together with
chown -R {user} /path/to/your/worpress/root
Replace {user} with apache web user.
UPDATE: (To install plugin without FTP details)
Please add following line to your wp-config.php after define('WP_DEBUG', false); line.
define('FS_METHOD', direct);
Remove plugin and re-install it, this time it wont ask you for FTP details and will write files directly.
For me, the solution was to add the mod_suexec apache module
Related
I am trying to install CiviCRM in my openshift wordpress 'gear' And I am getting the following when I attempt to run civicrm's installation wizard:
The user account used by your web-server - 542ddc2950044666c40008d9 -
needs to be granted write access to the following directory in order
to configure the CiviCRM settings file:
//var/lib/openshift/542ddc2950044666c40008d9/app-root/data/plugins/files
Does anyone know if what it is asking is possible?
and then how do I go about setting that?
Thanks!
The plugins/files/civicrm directory is where CiviCRM stores its cached templates, file attachments, premium (thank-you gift) images, and more. It'll need to save stuff there regularly, not just at first.
The best thing to do is to log in through SSH like developercorey recommends and:
cd ~/app-root/plugins
chmod 755 files (changing the permissions so the owner can write and everyone can read/execute)
chown 542ddc2950044666c40008d9:542ddc2950044666c40008d9 files (making the user that the web server runs as ("542ddc2950044666c40008d9" as mentioned in the error message) be the owner of the directory
have the installer check again
SSH into your gear using the rhc ssh command
cd ~/app-root/plugins
ls -lah
Look for the "files" directory and see what the user and the permissions are on that folder, you can change with the "chmod" command to allow it to be written to by the web server, but be careful what you do or you could cause a major headache for yourself (like getting your WP blog hacked). Hopefully the instructions for that plugin include setting the permissions to something reasonable when you are done.
I'm getting this error on an avatar upload on my site. I've never gotten it before and nothing was changed recently for me to begin getting this error...
Warning: is_writable() [function.is-writable]:
open_basedir restriction in effect.
File(/) is not within the allowed path(s):
Modify the open_basedir settings in your hosting account and set them to none. Find the open_basedir setting given under 'PHP Settings' area of your Plesk/cPanel. Set it to 'none' from the dropdown given there.
I have shown them in the Plesk panel picture.
To resolve this error, you must edit the file httpd.conf.
Way before it can be seen in phpinfo in apache2handler section directive Server Root.
For example, in my case this way - / etc / httpd / httpd.conf.
Open the file httpd.conf, find the mention of the parameter open_basedir. And set it to none. (php_admin_value open_basedir none)
If you're running this with php file.php. You need to edit php.ini
Find this file:
: locate php.ini
/etc/php/php.ini
And append file's path to open_basedir property:
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/etc/webapps/:/run/media/andrew/ext4/protected
For me the problem was bad/missing config values for the Plesk server running the whole thing.
I just followed the directions here:
http://davidseah.com/blog/2007/04/separate-php-error-logs-for-multiple-domains-with-plesk/
You can configure PHP to have a separate error log file for each VirtualHost definition. The trick is knowing exactly how to set it up, because you can’t touch the configuration directly without breaking Plesk.
Every domain name on your (dv) has its own directory in /var/www/vhosts. A typical directory has the following top level directories:
cgi-bin/
conf/
error_docs/
httpdocs/
httpsdocs/
...and so on
You’ll want to create a vhost.conf file in the domain directory’s conf/ folder with the following lines:
php_value error_log /path/to/error_log
php_flag display_errors off
php_value error_reporting 6143
php_flag log_errors on
Change the first value to match your actual installation (I used /tmp/phperrors.log). After you’re done editing the vhost.conf file, test the configuration from the console with:
apachectl configtest
…or if you don’t have apachectl (as Plesk 8.6 doesn’t seem to)…
/etc/init.d/httpd configtest
And finally tell Plesk that you’ve made this change.
/usr/local/psa/admin/bin/websrvmng -a
Laravel
If you have this problem when using Laravel.
Only go to folder bootstrap/cache and rename config.php to anything you want and reload site.
If used ispconfig3:
Go to Website section -> Options -> PHP open_basedir:
In this field has described allowed paths and each path is separated
with ":"
/var/www/clients/client2/web3/image:/var/www/clients/client2/web3/web:/var/www/...
and so on
So here must put the path that you want to have access, in my case is:
/var/www/clients/client2/web3/image:
The problem appears because:
When a script tries to access the filesystem, for example using include, or fopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to access it.
The path you're refering to is incorect, and not withing the directoryRoot of your workspace. Try building an absolute path the the file you want to access, where you are now probably using a relative path...
if you have this kind of problem with ispconfig3 and got an error like this
open_basedir restriction in effect.
File(/var/www/clients/client7/web15) is not within the allowed
path(s):.........
To solve it (in my case) , just set PHP to SuPHP in the Website's panel of ispconfig3
Hope it helps someone :)
I had this problem # one of my wordpress sites after updating and/or moving :)
Check in database table 'wp_options' the 'upload_path' and edit it properly...
For Plesk, you can change or set the openbase dir settings via the panel
https://support.plesk.com/hc/en-us/articles/360006170513-How-to-add-custom-or-additional-path-to-the-open-basedir-option-for-Plesk-domain-
Edit the php.ini or .user.ini that is located within the main directory
open_basedir = none
If you are running a PHP IIS stack and have this error, it is usually a quick permission fix.
If you administer the windows server yourself and have access, try this FIRST:
Navigate to the folder that is giving you grief on writing to and right click it > open properties > security.
See what users have access to the folder, which ones have read only and which have full. Do you have a group that is blocking write?
The fix will be specific to your IIS setup, are you using Anonymous Authentication with specific user IUSR or with the Application Pool identity?
At any rate, you are going to end up adding a new full write permission for one of IUSR, IIS_IUSRS, or your application pool identity - like I said, this is going to vary depending on your setup and how you want to do it, you can go down the google rabbit hole on this one (one such post - IIS_IUSRS and IUSR permissions in IIS8) For me, i use anon with my app pool identity so i can get away with MACHINE_NAME\IIS_IUSRS with full read/write on any temp or upload folders.
I do not need to add anything extra to my open_basedir = in the php.ini.
In addition to #yogihosting's answer, if you are using DirectAdmin, then follow these steps:
Go to the DirectAdmin's login page. Usually, its port is 2222.
Login as administrator. Its username is admin by default.
From the "Access Level" on the right panel, make sure you are on "Admin Level". If not, change to it.
From the "Extra Features" section, click on "Custom HTTPD Configurations".
Choose the domain you want to change.
Enter the configurations you want to change in the textarea at the top of the page. You should consider the existing configuration file and modify values based on it. For example, if you see that open_basedir is set inside a <Directory>, maybe you should surround your change in the related <Directory> tag:
<Directory "/path/to/directory">
php_admin_value open_basedir none
</Directory>
After making necessary changes, click on the "Save" button.
You should now see your changes saved to the configuration file if they were valid.
There is another way of editing the configuration file, however:
Caution: Be careful, and use the following steps at your own risk, as you may run into errors, or it may lead to downtime. The recommended way is the previous one, as it prevents you from modifying configuration file improperly and show you the error.
Login to your server as root.
Go to /usr/local/directadmin/data/users. From the listed users, go to one related to the domain you want to change.
Here, there is an httpd.conf file. Make a backup from it:
cp httpd.conf httpd.conf.back
Now edit the configuration file with your editor of choice. For example, edit existing open_basedir to none. Do not try to remove things, or you may experience downtime. Save the file after editing.
Restart the Apache web server using one of the following ways (use sudo if needed):
httpd -k graceful
apachectl -k graceful
apache2 -k graceful
If your encounter any errors, then replace the main configuration file with the backed-up file, and restart the web server.
Again, the first solution is the preferred one, and you should not try the second method at the first time. As it is noted in the caution, the advantage of the first way is that it prevents saving your bad-configured stuff.
Hope it helps!
I am using an Apache vhost-File to run PHP with application-specific ini-options on my windows-server. Therefore I use the -d option of the php-command.
I am setting the open_basedir for every application as one of these options.
I needed to set multiple urls as open_basedir, including an UNC-Path, and the syntax for this case was a bit hard to find. You have to seperate the paths with semicolons and if your first path starts with a driveletter you might have to start the list with a semicolon too. At least that's what works for me.
Example:
php.exe -d open_basedir=;d:/www/applicationRoot;//internal.unc.path/ressource/
I uploaded my codeigniter project on Directadmin panel. I was getting same error.
Then I change in php settings.
open_basedir =
session.save_path = ./temp/
Then it worked for me.
As most do not find a solution, the solutions are broad for WordPress most even don't know fully why things are they are.
I've found out you will have to enable IP for your server in especially when using Cerber in some cases it can think you are not uploading .png instead you are uploading .js files.
The server IP needs to be whitelisted. Even the uploaders in some rare cases.
A great to know is to have a tmp folder 755 in your base directory, you actually do not need a folder called tmp.: "Also remember / properly inedited as below:
open_basedir = "/home/user/site.com/:/tmp"
upload_tmp_dir = /home/user/site.com/tmp
The best option for quick setup is in Cpanel where you use the MultiPHP INI Editor you can actually save and both .htaccess and php.ini will be updated as well as settings being initiated at the same time on site.
It's NOT recommended to have basedir as "none" since you are enabling root files that can be edited with just a single file editor in WordPress. If that truly is possible.
Check \httpdocs\bootstrap\cache\config.php file in plesk to see if there are some unwanted paths.
Just search
open_basedir =
in php.ini and disable it. That's the simplest solution to solve this issue.
Before Changes open_basedir =
After Changes ;open_basedir =
P.s - After changes don't forget to restart your server.
Enjoy ;)
Modify the open_basedir settings in your PHP configuration (See Runtime Configuration).
The open_basedir setting is primarily used to prevent PHP scripts for a particular user from accessing files in another user's account. So usually, any files in your own account should be readable by your own scripts.
Example settings via .htaccess if PHP runs as Apache module on a Linux system:
<DirectoryMatch "/home/sites/site81/">
php_admin_value open_basedir "/home/sites/site81/:/tmp/:/"
</DirectoryMatch>
I am unable to upload themes to my WordPress installation via WordPress admin. I am getting the following error:
The uploaded file could not be moved to /home/debiprasad/webapps/wordpress/wp-content/uploads/2011/09
The permission of wp-contents directory and all sub directories are: 0755. Some people may suggest to make it 0777. This may work, but I don't think this is the correct solution. Because, all the folders should be have permission 0755 and this is secure. 0755 is the default and it works in other installations.
I want to know what's the reason of this error and what is the perfect and secure solution?
Assuming you use Apache, is your uploads folder owned by www-data? (or whatever user apache/php run as?)
If you have access to change ownership, 0755 should work as long as the upload folder (and subdirectories within) are owned by the same "user" that the web server runs as - so in most cases, that'll be www-data.
If this doesn't work, what method do you use to install themes? ftp, ftps or ssh2?
I am deleting files (wordpress theme files )of my website to the server using cPanel, but still the files are reappearing. The files have a 000 permissions set.
It is strange that files have proper permissions ( i.e. 777) when they are on my local machine, but on uploading they are getting changed to 000. Do you think the site is infected by virus ? I run an Anti-Virus scan, and found none.
Any reason why this may be happening?
chmod 000 denies read, write, and execute permission to yourself, your group, and everyone else.
How are the files uploaded to the server? Your FTP program might me screwing up the files when they are uploaded.
If you have root access you should be able to remove using $ rm -rf filename
Edit
The Umask settings on your server are not right. Setting Umask to 777 will make permissions 000.
If you have shell access you can check for 777 Umask values by running: grep 'umask 777' /etc/skel/.bashrc
If you find anything change the Umask to 022. If you don't have shell access your host should be able to fix this for you.
Instead of using the cpanel uploader use a an FTP program like Transmit for Mac or Core FTP Pro for windows and make sure to always use SFTP which is encrypted instead of FTP.
If you have the option, use FTP to manage your server files. It's more reliable than any web-based client.
If not, try changing permissions through cPanel to 777 before deleting them. If you are unable to do that, then contact the server administrator to resolve the issue (since it looks like a server/cpanel misconfiguraiton).
This is caused by the server recreating folders because you have subdomains or email addresses still attached to the domains related to those folders. Delete the subdomains and emails related to them and those folders will stay deleted.Happened to me before :)
Tim
backup other files in folder then delete folder.
create new folder with previous folder name (that was you deleted) and copy backuped files to it.
This may just work for other users who don't know how to do the techies, or who don't have shell access:
Check to see whether what you want to delete is a FOLDER or a FILE
If it is a FOLDER, check the permissions on that FOLDER and change to 755, do the same if it a FILE and simply delete
The issue here is that you have to open the FOLDER and CHANGE ALL SUBFOLDERS and FILES inside it to permission settings 755.
Delete the files from the inside of the SUBFOLDERS out then to the FOLDERS
This should perhaps help someone.
This has to do with media uploading in Wordpress.
Every time WP creates a folder for new uploads (it organizes uploads by year and month: yyyy/mm), it creates it with the "apache:apache' user and group, with full access to all (777 or drwxrwxrwx).
However, after that, WP cannot create a folder within that folder (e.g.: mkdir 2011 succeeds, but mkdir 2011/01 fails). Also, uploads cannot be moved into these newly created folders even though the permissions are 777 (rwxrwxrwx).
Once a month, I have to chown the newly created folders to be the same as user:group as the rest of the files. Once I do that, uploading works fine (which doesn't make sense to me The really frustrating part is that this problem doesn't exist in other WP installs on other domains on the same server.
* I wasn't sure if this should be here or on serverfault.
Edit: The containing directory /.../httpdocs/blog/wp-content/uploads has the correct ownership
drwxrwxrwx 5 myuser psaserv 4096 Jun 3 18:38 uploads
This is a Plesk/CentOS environment hosted by Media Temple (dv).
I've written the following test script to simulate the problem
<pre><?php
$d = "d" . mt_rand(100, 500);
var_dump(
get_current_user(),
$d,
mkdir($d),
chmod($d, 0777),
mkdir("$d/$d"),
chmod("$d/$d", 0777),
fileowner($d),
getmyuid()
);
The script always creates the first directory mkdir($d) successfully. On domain A, where the WP problem is, it cannot create the nested directory mkdir("$d/$d"). However, on domain B, both directories are successfully created.
I am running each script at /var/www/vhosts/domainA/httpdocs/tmp/t.php and /var/www/vhosts/domainB/httpdocs/tmp/t.php respectively I checked the permissions on tmp, httpdocs, and domain[AB] and they are the same for each path. The only thing that differs is the user.
A solution is to use FastCgi. This makes PHP run as the user who owns the site. New files and folders will be the same user and group. This will solve your problem.
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.
Try going to your miscellaneous settings page (or media depending on your version) and make sure the upload directory is still wp-content/uploads.
If you need to. set the full url too.
Also, as a final solution, disable the option to organize them into folders so that way WordPress doesn't even need to create folders.
Check for a setuid or setgid bit on a directory above the 2010 directory. ls -l will have an s or S in the permissions for the directory. Make sure this directory has the correct ownership.
Try to create directory recursive with mkdir($d, true)
<pre><?php
$d = "d" . mt_rand(100, 500);
var_dump(
array(
get_current_user(),
$d,
mkdir($d,true),
chmod($d, 0777),
mkdir("$d/$d", true),
chmod("$d/$d", 0777),
fileowner($d),
getmyuid()
)
);
I had a similar issue with Joomla recently, and solved the problem by adding myuser into the apache group, and add apache into the psaserv group.
One of our websites on a Media Temple DV was having this problem. Turning PHP Safe Mode off solved it. The directories were still created as apache:apache, but the media files were allowed in there.
One thing that occurred to me - WP will tell you that it can nto copy file to /wp-content/upload even when all permissions are right.... if
upload_max_filesize
in php.ini is too small (say 2M and you try to upload 3.5MB file)!
Hope that helps all thsoe who have right permissions but still can not upload!
You shouldn't need 777 on your directories, 775 at most should be sufficient. Just make sure it's set on the uploads directory with 755 for all the other directories above.
Also, you could try to chown it to www-data, sometimes that helps when your ftp user that you are logged in as when changing the permissions once a month doesn't have sufficient access level and owning the directories by that user prevents the server from being able to write into them.
Lastly, as someone has pointed out above, you may need to up the upload size limit along with making sure other file upload related php.ini settings are correct:
http://php.net/manual/en/ini.core.php
http://kb.mediatemple.net/questions/137/How+can+I+edit+the+php.ini+file%3F#dv
One common cause, often overlooked, is the disk quota, ie have you run out of disk space.