After moving php-files from windows to linux(centos) I started getting the following permissions errors:
ERRNO: 2
TEXT: rename(/tmp/wrtwetuti,/var/www/site1/presentation//compile_dir/ee63ba1108c61f830b5d6155f21b1bcd04684f7e.file.category.tpl.php): Permission denied
LOCATION: /var/www/site1/libs/smarty_3/sysplugins/smarty_internal_write_file.php, line 48, at September 9, 2011, 4:05 am
When for testing purposes chmoded compile_dir to 777, the problem goes away.
I wonder if anybody knows a solutions for it.
Would installing suPHP solve this problem?
compile_dir is supposed to be writable by the web server (and also outside your web root). So you should:
move it out of your web root
assign ownership to the web server user
chmod it to 700
The fact that on your Windows install the default compile_dir was also writable by the web server is typical for that OS, and doesn't mean that there is something to fix on Linux.
You can look at this page: http://www.smarty.net/docs/en/installing.smarty.basic.tpl
"Smarty will need write access (windows users please ignore) to the $compile_dir and $cache_dir directories (templates_c/ and cache/), so be sure the web server user account can write to them".
hope this helps.
Related
I'm installing WordPress through Xampp. I used to work with MAMP and it basically works the same way.
Normally I do everything manually as in copying the files and installing the database.
When loaded the famous "can't establish database connection" kicks in.
Now I thought this might have something to do with the fact that MAMP and Xampp have some minor differences. So I decided to use the WordPress installer.
After placing the files in XAMPP->xamppfiles->htdocs->customFolder I ran the installer.
Database is created in phpMyAdmin and I expect the installer to finish after adding the credentials. But nooooo. For some reason this sob keeps denying the wp-config.php to be created.
I quadruple checked every credential of the database. Have no idea on why step2 fails to install WordPress.
So I might think this is an port issue. I have also installed MAMP and it is running on port:8080. After setting xampp to port:8080 it gives me an error saying it can't bind to that port. Changed it to port:8666 but the same problem occurs.
Any thoughts or extra info?
---- UPDATE ---
So I created the wp-config.php manually and got these extra error messages.
All files in the htaccess folder have now file permission 777. This is merely for testing and would never happen in a live environment.
Warning: mysqli_real_connect(): (HY000/1045): Access denied for user 'root'#'localhost' (using password: YES) in /Applications/XAMPP/xamppfiles/htdocs/testing/wp-includes/wp-db.php on line 1531
There must be file permission issue, You must grand 777 rites to create wp-config file. chmod 775 wp-content/upload
Also note
All files should be owned by the actual user's account, not the user account used for the httpd process.
Group owneraship is irrelevant, unless there's specific group requirements for the web-server process permissions checking. This is not usually the case.
All directories should be 755 or 750.
All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to prevent other users on the server from reading it.
No directories should ever be given 777, even upload directories. Since the php process is running as the owner of the files, it gets the owners permissions and can write to even a 755 directory.
It sounds like a folder/file permissions issue rather than a port issue.
This question should help you solve the permissions on your xampp/xamppfiles/htdocs/customfolder
XAMPP permissions on Mac OS X?
When WordPress gives that error it's most often because it can't create the wp-config.php file due to insufficient write permissions.
I found the solution.
MAMP uses a user root and password root.
XAMPP in contrast to MAMP doesn't.
The user name is root but the password is empty.....
I faced this issue attempting to install within XAMPP and what solved it for me was to run XAMPP as administrator. This reflects other answers referring to permissions.
The other thing that can be an issue is XAMPP timing out on the install. One can modify their php.ini file within xampp to increase the max execution time. As they say "I hope this helps"
;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 90
I had same issue using XAMPP 8.1.12 on WINDOWS 10;
Try installing an older version, in my case XAMPP 8.0.25 fixed the problem.
Recently, I moved a website to live and all the file related operations stopped working, for e.g., copy, imagecreatefromjpeg, etc due to permissions issue.
All the files are created in files/ directory. I gave it 755 permission recursively for directories and 644 permission to all the files. Still the PHP functions didn't work. It works only if I give 777 permissions (not even 775 works).
I checked the permissions for other live projects. They had 755 for directories and 644 for files, and still they seem to work fine without any permission issues.
Could anyone please explain me the reason for this issue on this specific website?
Thanks
It sounds like an ownership issue.
To test, create a folder on the server with 777 perms (e.g. tmp, perhaps in your document root).
And then create a script (alongside tmp) that does a simple write to that folder.
<?php
file_put_contents(__DIR__ . '/tmp/test.txt', 'hello earth');
Then look at the ownership and permissions of the resultant file.
On my dev server I have Php running under the web server Apache (using mod php) on Linux (Debian). And scripts run as the user 'www-data'. So the key here is that the user www-data needs to be able to write to the folder.
If the folder isn't writable by the web server, then something like the following error is in the apache error logs:
[Tue May 10 08:27:52.404959 2016] [:error] [pid 18] [client 172.17.42.1:59832] PHP Warning: file_put_contents(/var/www/stackoverflow/tmp/test.txt): failed to open stream: Permission denied in /var/www/stackoverflow/so_test.php on line 3, referer: http://localhost/
Try and understand your server environments and unix permissions.
In my first PHP script in many years, I'm trying to log an error:
error_log("my error message", 3, $error_log);
I'm getting an error in the general Apache error log:
PHP Warning: error_log(/var/log/apache2/my_php_errors.log): failed to open stream: Permission denied in /var/www/html/blahblah/my_script.php on line 88
This is what I've checked and tried:
Created $error_log with the same ownership (root.adm) and permissions (640) as the Apache error log.
Changed the owner to www-data, which is the user PHP is running as.
log_errors is On.
open_basedir is not set.
Using PHP 5.5.x, so safe mode does not exist.
What am I missing?
Edit: It's able to write to the general Apache error log. The mystery is why it can't write to another file in the same directory with the same ownership and permissions.
Edit 2: Another developer told me that this works on his WAMP, so it's something specific to my LAMP stack or config.
I had the same problem.
https://serverfault.com/questions/831444/php-error-log-per-vhost/831666#831666
touch /path/to/php_error.log
chown www-data:www-data php_error.log
chmod 755 php_error.log
thanks for leading me to the answer!
TL;DR: check that all the ancestor directories allow reads/lists by the web server.
On my system, my equivalent of /var/log/apache2/my_php_errors.log was giving this same error. I eventually did an ls -ld at every level of the path (/, /var/, /var/log/, /var/log/apache2/, /var/log/apache2/my_php_errors.log).
Four of those had permissions that made them readable by the web server. One of them, /var/log/apache2/ did not. When I moved my file out of the apache2 directory, everything started working. E.g. /var/log/php/ and set appropriate permissions/ownership (e.g. 750 by www-data.adm) on the new directory.
prompt> ls -ld /var/log/php/
drwxr-x--- 2 www-data adm 4096 Nov 1 13:31 /var/log/php/
You could also change the permissions on /var/log/apache2/, but that seems like a security/privacy issue. It's safer to make a new directory and leave the existing structure as is.
The reason why the permissions have to change is that it is no longer using some version of syslog to publish to the log files. The syslog variants run as root and accept messages from non-root. But in my case, I was specifying the file from the web server, which made the permissions wrong.
There is a fix that uses syslog so that it could keep the same ownership. I did not try to make that work, as this is for a test server.
This may not have been the problem that you were having, but I'm pretty sure that I was using the default permissions for /var/log/apache2/. So it's quite possible that it was the problem. And even if it wasn't, this is one of the places I was searching for troubleshooting advice. So next time something like this happens to me, I'll have a reminder of what to check.
I have seen many questions and answers on this topic but none seem to help my situation. My PHP code is successfully creating a new logfile, but then cannot access that file to append further info, close it, etc.
I am migrating an application from local XAMPP onto LAMP: hence problem only showing up now due to Windows/XAMPP giving no permission troubles.
I started with a default Bitnami LAMP stack, and then manually setup relevant directory permissions on server:
- my sftp user has rwx on htdocs and assorted out-of-web-root directories
- apache is running as 'daemon' so I have given read & execute permissions to relevant directories for 'daemon' as group
- in most directories I have disallowed write permissions for 'daemon'
- however for my (application generated, internal) logs I have a 'logfiles' directory which has rwx for both my user and the 'daemon' group
- 'other' is -rwx for all
When I run my application it falls over pretty much immediately. The error logs showing fopen failed to open stream: permission denied. However, the permissions indicate that it should have access.
When I check the file involved it has following permissions:
-rw-r--r-- 1 daemon daemon 962 Oct 3 10:14 20151003logfile03-10-33530.txt
This tells me that the file was created by Apache (i.e. by my PHP script) and that it has read and write permissions, from when I fopen() with "w"
EDIT: adding directory info:
Folder level permissions give my ftps user and daemon (group) full rwx access:
drwxrwx--- 2 ftpuser daemon 4096 Oct 3 10:30 logfiles
BUT it can't then fopen with "a"
I am assuming that this IS a file permission problem because:
a) it works fine on XAMPP
b) it states permission error in the error log
However, I can't see why it should be a problem, given directly-specified OS-level permissions ... maybe Apache requires an .htaccess 'allow' on this directory also?
Any ideas?
Clarification re why I don't think CHMOD is the answer (sorry #RedAcid):
CHMOD 777 etc is simply a way to set the underlying permissions I already have. Each digit represents 3 binary chars, so 7 is 111 (i.e. read, write and execute). As you can see above, I have read/write/execute for PHP/Apache on folder, together with read/write for file. What I've read suggests that you need execute at directory level, but not at file level because its not trying to execute the file.
So what am I missing here? Why else might it be denying permission?
use chmod 666 for the file and proper user group permissions. folder where files are located must be writable with chmod 777
OK - I found out the problem was higher level parent directory not having read/execute permissions. Now working! (AT LAST!)
For more detail see this previous question:
PHP fopen() fails on files even with wide-open permissions
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.