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.
Related
I have a centOS -based virtual machine on digital ocean.
It is running NGINX HTTP sever.
I configured it to use multi domains, and set up SSL.
One of my domains runs a Wordpress application.
I migrated the WordPress files from my godaddy hosting.
Everything works great except when I try to upgrade the wordpress core ( updating and installing plugins works just fine).
When I try to upgrade WordPress to version 5.4.2 I get a permissions error (as shown in attachment photo):
Permission denied in /var/www/mydomain.com/wordpress/wp-admin/includes/class-wp-filesystem-direct.php on line 281
wordpress core upgrade file permissions error display
I tried doing the following just to diagnose the issue... I have the directory full access to nginx user:
chmod -R 777 /var/www/
chown nginx:nginx /var/www/
This did not work
I made sure php user is nginx by outputting echo exec('whoami'); on the page.
I am completely dumbfounded.
Does anyone know what the problem may be?
As a last resort I manually upgraded my wordpress version using FTP, but I'm concerned that I never figured out the root cause of this issue and it will spring back up again opening up a can of worms.
CentOS includes a mandatory access control (MAC) security mechanism in its Linux kernel by the name of SELinux. According to a support forum thread on Wordpress.org, this mechanism sometimes can cause issues that manifest with this error.
SSH into your server and use the following command to change the SELinux "context" for the entire /var/www/mydomain.com folder:
chcon -R –-type httpd_sys_rw_content_t /var/www/mydomain.com/
The last post in the above-linked thread indicated that this change of context alleviated the errors you're seeing.
As an aside, for your system's security, ensure you change your file permissions back to their defaults.
A client informed me that any time he tries to update a plugin, he gets an error:
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.
I don't have FTPd setup on the server, but this seems like a basic permissions issue, right? I've never had to use FTP credentials to update any other WordPress installations.
Well, I did some reading and started messing with permissions and long story short, out of frustration, I eventually made everything writeable by everybody:
sudo chmod -R 777 src
But I'm still getting the same error. So it has to be some type of configuration issue, right?
I ran a few find . -exec grep commands to determine if there is a hard-coded document root (like in Joomla), but I came up empty handed.
Do I really have to install FTPd to be able to update WordPress from the admin interface?
Is there a config file somewhere that specifies the document root location?
Is there some other configuration option that I'm missing here?
Or maybe it's something in the database? The site was originally on a shared host but was moved to a DigitalOcean VPS a month or so ago.
I was able to force WordPress to use the filesystem instead of FTP by setting the FS_METHOD constant in wp-config.php:
define('FS_METHOD', 'direct');
More details can be found in the WordPress codex.
Try running chown -R apache:apache on the directory. I recall running in to an issue with ownership even when permissions were OK. You may have more success posting this on ServerFault as well.
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 am running Sugarcrm CE under wamp on a windows 7 machine and I keep getting the following error. It just happens randomly and if I reload the page it seems to work. But this error is very annoying and I never used to get it under this development environment. I know if this was linux it would be a permissions issue but permissions look fine in windows to me. I have developer mode switched on and have deleted the cache folder but it still happens. Does anybody know how to prevent this?
Fatal error: sugar_file_put_contents_atomic() : fatal rename failure 'E:\wamp \www\sugargantt-project\cache\modules\Employees\tem177F.tmp' -> 'cache/modules/Employees/Employeevardefs.php' in E:\wamp\www\sugargantt-project\include\utils\sugar_file_utils.php on line 187
I had the 'cache' directory but found it was owned by 'root' so I resolved it by correcting ownership from the sugarcrm directory:
chown -R apache:apache .
Where 'apache' is your web server user.
I had this error and fixed it by editing the realpath_cache_size setting from the default of 16k to 32k in my php.ini.
realpath_cache_size = 32k
EDIT: Although, the above solution helped, this issue returned in my local development environment (I am running on Windows 7). I ended up resolving it by closing my PHP IDE, PhpED by NuSphere, and deleting the localhost debugging cookie in my browser that this IDE sets named "DBGSESSID". I re-ran my local sugarCRM instance again without PhpED and the error disappeared.
I was also facing this issue and resolved it by performing following steps
The root folder of sugar must have a folder named 'cache' in which it creates the cache files.If the folder is missing then create one.
Increase the Memory usage and script execution time in php.ini file, i had set these to Memoray: 256, Script execution time to 1000.
Visit http://localhost/?phpinfo=1 and see if WinCache or APC are enabled. They're both caching mechanisms for PHP on Windows environments, and I've had similar issues with such things in Sugar where temporary files aren't able to be deleted and rebuilt correctly.
If one or the other are enabled, you'll want to modify your active php.ini file or otherwise disable the PHP module from the WAMP menu.
Just create a cache directory in root directory of sugarcrm and check permission on it make it 777 and try hard reload it after this
After moving a site from local to remote server. I cannot get the magento conect manager to install extensions. No obvious info regarding this paticular error online.
If give an extension url....it will show the preloader for a few seconds, before returning to the connect page, with no error.
If use the package uploader, initially i had a 'could not move files' error...but changing certain dirs to 777 fixed this. I did set all folders to 777, to test if this helped. It didnt.
Anyone know this error? Otherwise manual extension installs for me :(
Could this be apache related....or moving files via FTP from local to remote server? I say this based on some forum posts i read.
Thanks
S
If the following files exist try removing (or renaming if you prefer to be safer) them.
downloader/connect.cfg
downloader/cache.cfg
These are generated by Magento the first time you use connect. The cache file stores a full path to your install, so when you move to a new server this likely isn't a valid path.
chmod 777 var/package/tmp/package.xml
should do the trick.
the directory is from your magento home directory.
Maybe you run out of disc space. I raised disk quota on my server for this account, and the problem disappeared.
If you have SSH/CLI access and are using Magento 1.5+, try running ./mage mage-setup .
If you're on Magento 1.3.x or 1.4.x delete the files in /downloader/pearlib/cache/ and try again.
If you have cpanel hosting where the apache is configured to work with users such as nobody, apache etc.. then the problem is that. the owner of /home/user/public_html/var/package/tmp/package.xml will your cpanel user but this requires apache users permission. so the choice is to temporarily change the file permission to 777