What I did
Last night while updating plugins on my Wordpress site my site crashed and I had to spin up a new server and restore from a Vaultpress backup. Once the restore had finished propogating I was unable to update the plugins so I ran the command
chown -R www-data:www-data /var/www/html/
I got the response
-bash: cd: /var/www/html: No such file or director
So after a bit of snooping I determined my directory path was off slightly. So, I ran
chown -R www-data:www-data /var/www/html/html.old
What happened
After running the chown command when I attempt to install plugin updates I get this in-browser error message:
Not Found
The requested URL /wp-admin/plugins.php was not found on this server.
Apache/2.4.29 (Ubuntu) Server at $domain Port 80
My question
Obviously I broke something when I ran the chown command, so how do I undo the command that I ran?
Any help would be very much appreciated
I don't think it's possible to revert the chown command unless you have a backup or know which file belongs to whom or all files belonged to a single user, which I doubt is the case here.
Related
I recently installed Wordpress using XAMPP local testing environment.
When I tried to run updates for my plugins, it asked me for FTP credentials and would not go any further.
I ended up running the following command which solved the issue:
sudo chown -R daemon /mysite/
Could someone explain why I would need to do this ?
When I ran the command ls -l /mysite/ before I did anything, it showed the user and group as me:me but when I ran the command:
sudo chown -R me:me /mysite/
it made no difference.
mysite permissions were set to 755 before I changed ownership.
Thanking you in advance.
The ftp credentials you can solve by adding
define( 'FS_METHOD', 'direct' );
to wp-config.php, at the very end.
As to your other problem, I'struggling with the same right now. What works (sort of) for me is to set the entire site to
sudo chown -hR daemon:deamon /opt/lampp/htdocs/yoursite
Now you can install plugins.
change to
sudo chown -hR me:deamon /opt/lampp/htdocs/yoursite
to work on the files. For every change you have to do that.
It's not the right way to work, but the best bad solution I can find so far.
I know there are bunch of posts all over the internet about the WordPress permissions, but I am facing an issue I can't explain from the other posts. I am running debops WordPress on Ubuntu 16.04 with nginx.
Basically my updates within WordPress are failing, I am getting the "Could not create directory error". So I checked the permissions, and they are all correct (755 for the directories, 644 for the files).
Furthermore I checked that nginx is actually running as www-data user, which it does:
ps aux|grep nginx|grep -v grep
Shows that nginx is running as www-data.
To verify the permissions, I tried:
sudo -u www-data mkdir test
which worked and created the test directory.
Then some other posts made me think it has to do with a FTP configuration, most of them point to the vsftpd.conf file, but I don't have vsftpd installed (though I am able to connect via sftp to the ubuntu machine).
Question: What other reasons might cause this issue? Technically, WordPress has all the permissions to create it's directories.
Ok I found the problem:
nginx was indeed running as www-data user, but that wasn't the issue. From the debops issues I found that the correct user who should own the WordPress directory is the 'wordpress' user, not www-data.
chown wordpress:wordpress /var/www/ -R
Now everything works well with the updates.
I use the Google cloud launcher to start a fresh Wordpress.
with the following VM :
Machine type
f1-micro (1 vCPU, 0.6 GB memory)
CPU platform
Intel Ivy Bridge
Zone
us-central1-f
It was launched with an older version : 4.5.3-1
I tried to do an automatic update. it didn't work, and showed
The update could not be unpacked
Installation Failed
I tried following tutorials on
https://community.bitnami.com/t/automatic-update-wordpress-4-6-is-not-working/43814/4
Connect to your server via SSH and execute:
sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs/wp-content
sudo chmod -R g+w /opt/bitnami/apps/wordpress/htdocs/wp-content
Doesn't work for my case,
I also tried to use follow manual update https://codex.wordpress.org/Upgrading_WordPress.
Delete the old wp-includes and wp-admin directories on your web host (through your FTP or shell access).
using filezilla ftp , i get a lot permission denied errors of different file names.
Error: rm /opt/bitnami/apps/wordpress/htdocs/wp-includes/customize/class-wp-customize-partial.php: permission denied
Please advice. how can i update this thing?
Anyone facing the same issue?
Google should put back their own wordpress.
You can try the following workaround to upgrade your old WordPress to the latest version:
Open /opt/bitnami/apps/wordpress/htdocs/wp-config.php
Look for define('FS_METHOD', 'ftptext');
Replace it with define('FS_METHOD', 'direct');
Change the permissions of /opt/bitnami/apps/wordpress/htdocs to allow the server user (daemon) to make the modifications. You can do that by executing sudo chown -R daemon /opt/bitnami/apps/wordpress/htdocs
Go to the WordPress admin panel and perform the automatic upgrade.
Change the permissions of /opt/bitnami/apps/wordpress/htdocs to it original ones. To do that, execute sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs
Replace again the define('FS_METHOD', 'direct'); line with define('FS_METHOD', 'ftptext'); in the wp-config.php file
Hope it helps.
Today, I installed testlink. And after I select 'new Installation' and choose 'I agree' option, it failed at the second step. The failed message are as following:
Read/write permissions
For security reason we suggest that directories tagged with [S] on following messages, will be made UNREACHEABLE from browser
Checking if C:\xampp\htdocs\testlink\gui\templates_c directory exists OK
Checking if C:\xampp\htdocs\testlink\gui\templates_c directory is writable (by user used to run webserver process) OK
Checking if /var/testlink/logs/ directory exists [S] Failed!
Checking if /var/testlink/upload_area/ directory exists [S] Failed!
So, can anyone give me a hand? Many thanks!
In C:\xampp\htdocs\testlink\config.inc.php file, change
$g_repositoryPath = 'C:\xampp\htdocs\testlink\upload_area';
$tlCfg->log_path = 'C:\xampp\htdocs\testlink\logs';
Worked for me , make sure you dont have the slash at the end.
i.e, make sure that it is NOT:
$g_repositoryPath = 'C:\xampp\htdocs\testlink\upload_area\';
$tlCfg->log_path = 'C:\xampp\htdocs\testlink\logs\';
If you installed the XAMPP or testlink in another directories, change the paths above accordingly.
Go to config.inc.php and log directory ($tlCfg->log_path) edit the path to C:\xampp\testlink\logs and upload directory ($g_repositoryPath) to C:\xampp\testlink\upload_area
In some cases, you would do like this:
Go to C:\xampp\htdocs\testlink\config.inc.php1
and log directory ($tlCfg->log_path) edit the path to C:\xampp\htdocs\testlink\logs
and upload directory ($g_repositoryPath) to C:\xampp\htdocs\testlink\upload_area
Then you have:
$g_repositoryPath = 'C:\xampp\htdocs\testlink\upload_area';
$tlCfg->log_path = 'C:\xampp\htdocs\testlink\logs';
I had paths set correct , also user, group and access are set correct and still can not get rid of issue. It took me very long to go to the root cause, the issue lies at- http daemon does not have access to file in concern due to SELinux policies. So simple chown, chmod would not help(group and user access). For testlink 1.16 I resolved it with re-installing with sudo user, but for upgrade, an issue arose again even with sudo user.
And resolved issue by executing following commands, I hope this helps. (Note: You might have to mend attributes to run it successfully)
$chcon -t httpd_sys_content_rw_t "<path_to_testlink_folder>/gui/templates_c/"
$chcon -t httpd_sys_content_rw_t "/<path_to_testlink_folder>/upload_area/"
$chcon -t httpd_sys_content_rw_t "<path_to_testlink_folder>/logs"
$semanage fcontext -a -t httpd_sys_content_rw_t "<path_to_testlink_folder>(/.*)?"
$restorecon -R -v path_to_testlink_folder
Ubuntu 12.04 - All you have to do is chmod 777 these directories, Fails will become Pass.
~$ cd into /var/www/testlink
~$ sudo chmod 777 ./gui/templates_c/
~$ sudo chmod 777 ./upload_area/
~$ sudo chmod 777 ./logs/
Whatever the instructions say is total BS. Making these directories unreachable from browser is optional, and that created a confusion. if you chmod 777 them, your Fails will turn into pass and now you'll be able to proceed to step 3 of your testlink installation. Tested with testlink version 1.9.5.
For Mac OS Users try this in 1.9.19 version:
Make Sure with your folder name.
In config.inc.php file:
$tlCfg->log_path = TL_ABS_PATH . 'logs' . DIRECTORY_SEPARATOR;
$g_repositoryPath= TL_ABS_PATH . 'upload_area' . DIRECTORY_SEPARATOR;
After this if you got read write permission issue failed.
Goto testlink -> logs / upload_area -> press Command + I -> in Permission Enable Read Write to Everyone.
on Linux; ensure the paths are as follows:
$tlCfg->log_path
$g_repositoryPath
are
/var/www/html/testlink/logs/
/var/www/html/testlink/upload_area/
Valid for ubuntu 16.04 LTS add permisions
Change:
$g_repositoryPath = 'var/www/html/testlink/upload_area'; //linux user
$tlCfg->log_path = 'var/www/html/testlink/logs';
~$ cd into /var/www/testlink
~$ sudo chmod 777 ./gui/templates_c/
~$ sudo chmod 777 ./upload_area/
~$ sudo chmod 777 ./logs/
In CentOS go to /var/www/html/testlink-code-1.9.16 and edit the file custom_config.inc.php replace these two lines
// $tlCfg->log_path = '/var/testlink-ga-testlink-code/logs/'; /* unix example */
// $g_repositoryPath = '/var/testlink-ga-testlink-code/upload_area/'; /* unix example */
with
$tlCfg->log_path = '/var/www/html/testlink-code-1.9.16/logs/';
$g_repositoryPath = '/var/www/html/testlink-code-1.9.16/upload_area/';
Make sure you have disabled the selinux. If not to do so edit the file /etc/sysconfig/selinux and change the variable SELINUX to disabled and reboot the machine. Now these errors should have gone.
on ubuntu 18.04, will need to run
apt-get remove apparmor
in order to install it
To solve the problem :
Checking if /var/www/html/testlink-1.9.16/gui/templates_c directory is writable (by user used to run webserver process) on Centos 7.
Disable SELinux, and then restart your system.
You should no longer have this error message.
I am a newbie in php, mysql. I have written a hello.php script, which I am trying to copy into /var/www directory (and will later want to open it through web browser). The problem with the same is that I am not allowed to save/write any files in /var/www despite me being the root. I tried implementing steps in this question, but I get the following error when I process the third line
find /var/www/ -type f -exec chmod g+w '{}' ';'
chmod: changing permissions of `/var/www/index.html': Operation not permitted
I know symlink is also an option. I would want to be able to write/copy files directly to /var/www/ directory.
Any suggestions on what is going wrong?
it'matter of *unix permissions, gain root acces, for example by typing
sudo su
[then type your password]
and try to do what you have to do
Do you have a file in /var/www called hello.php already that has permissions on it? Maybe the system can't replace the file?
Although, root access should supersede any user on the system.
Have you tried applying permissions to the www folder?
If you can do this, try the following:
sudo chmod -R 777 /var/www
then do:
sudo cp hello.php /var/www
I only recommend doing this if you know 100% that it is ok to set permissions on the whole www folder. By the sounds of it, you are running on your own production server as most live/shared hosting servers are setup so that the www folder is not in the /var folder (instead it is in the home folder of the user).
Be VERY careful when doing anything with the sudo prefix though, you can seriously damage your system if you do it wrong.
Are you in a development environment ? If Yes, You can do
chown -R user:group /var/www
so you will be able to write with your user.
Execute the following command
sudo setfacl -R -m u:<user_name>:rwx /var/www
It will change the permissions of html directory so that you can upload, download and delete the files or directories
Encountered a similar problem today. Did not see my fix listed here, so I thought I'd share.
Root could not erase a file.
I did my research. Turns out there's something called an immutable bit.
# lsattr /path/file
----i-------- /path/file
#
This bit being configured prevents even root from modifying/removing it.
To remove this I did:
# chattr -i /path/file
After that I could rm the file.
In reverse, it's a neat trick to know if you have something you want to keep from being gone.
:)
sudo chown -R $USER:$USER /var/www
First off, this has nothing to do with php. This is a unix permission issue. You need to login as a superuser ( sudo/su ) and type your password, then try that command.
$ su
(type password )
\# your command
$ sudo command
$ (type password)
It might also help if you actually specified the operating system you use.
sudo cp hello.php /var/www/
What output do you get?
If none of the above works, you might be dealing with a vfat filesystem. Use "df" to check.
See http://www.charlesmerriam.com/blog/2009/12/operation-not-permitted-and-the-fat-32-system/ for more details.
First of all, you need to login as root and than go to /etc directory and execute some commands which are given below.
[root#localhost~]# cd /etc
[root#localhost /etc]# vi sudoers
and enter this line at the end
kundan ALL=NOPASSWD: ALL
where kundan is the username and than save it. and then try to transfer the file and add sudo as a prefix to the command you want to execute:
sudo cp hello.txt /home/rahul/program/
where rahul is the second user in the same server.
You just have to write sudo instead of su.
Then just copy the PHP file to the var/www/ directory.
Then go to the browser, and write local host/test.php or whatever the .php filename is.
Enter the following command in the directory you want to modify the right:
for example the directory: /var/www/html
sudo setfacl -m g:username:rwx . #-> for file
sudo setfacl -d -m g:username: rwx . #-> for directory
This will solve the problem.
Replace username with your username.
The problem is a privilege issue navigate to the var/www/
right-click in it and select open as admin
then continue your work