For when people want to remove a drupal installation from the server, the content within the sites/default directory is not deletable unless you have root privileges.

* What are the steps required to reproduce the bug?
ssh: rm -r default/ within the sites directory.

* What behavior were you expecting?
not to see the default/ directory anymore

* What happened instead?
unable to delete any of the content within that directory.

Please include as much information as you can:
OS = Windows Vista Business Edition
webserver name and version = Apache/2.0.54 (Unix) PHP/4.4.7 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2
PHP version = PHP Version 4.4.7
Drupal version = 6.0-dev
Drupal path = #
and everything else you might feel is relevant
-> MySQL: 5.0.24a
-> did not find an "uninstall drupal" feature within the admin section that could fix this problem.

Comments

sime’s picture

sime
any/any
Location Melbourne
commented
Status: Active » Closed (won't fix)

I'm a hack but I think if you added it, you should be able to remove it. Did you use some sort of script installer to install it? Or did you connect to the server with the root account to install, but then to delete you are connected as another user?

I'm marking won't fix because it's not a Drupal thing. On the file system, drupal is just a bunch of files.

But Try
rm -Rf default

otherwise, do a whoami and then a ls -la and feel free to post the results.

Cheers
Simon

jswaby’s picture

jswaby commented
Status: Closed (won't fix) » Active

In this version, Drupal actually creates these files.

I'm a hack but I think if you added it, you should be able to remove it. Did you use some sort of script installer to install it? Or did you connect to the server with the root account to install, but then to delete you are connected as another user?

I used the new installed that comes with Drupal 6, not fantastico or anything like that. Did I connect as root? No, the nice people at dreamhost.com aren't nice enough to give me root access on any of their servers.

I consider this a big problem because if you can't cleanly remove drupal from a system without root access, it actually effects the file system structure. This is the first time in my 2 and a half years of using drupal that this problem has come up.

[nash]$ rm -r default/
rm: descend into write-protected directory `default/'? y
rm: remove write-protected regular file `default//default.settings.php'? y
rm: cannot remove `default//default.settings.php': Permission denied
rm: remove write-protected regular file `default//settings.php'? y
rm: cannot remove `default//settings.php': Permission denied
[nash]$ rm -rf default/
rm: cannot remove `default//default.settings.php': Permission denied
rm: cannot remove `default//settings.php': Permission denied
[nash]$ rm -Rf default/
rm: cannot remove `default//default.settings.php': Permission denied
rm: cannot remove `default//settings.php': Permission denied

as per your suggestion:

[nash]$ whoami
jswaby
[nash]$ ls -al
total 24
dr-xr-xr-x 2 jswaby pg527995 4096 Jul 22 20:58 .
drwxr-xr-x 3 jswaby pg527995 4096 Jul 25 21:18 ..
-r--r--r-- 1 jswaby pg527995 6418 Jun 17 03:45 default.settings.php
-r--r--r-- 1 jswaby pg527995 6423 Jul 22 20:58 settings.php
[nash]$ rm -rf *
rm: cannot remove `default.settings.php': Permission denied
rm: cannot remove `settings.php': Permission denied

Now do you see the problem? It's directly related to the new installer.

Please Simon, if you have any other suggestions on how to deal with this, please post. But I'm pretty sure this is a drupal problem.

sime’s picture

sime
any/any
Location Melbourne
commented

Thanks for posting the extra info. My hacks are depleted, the floor is open :)

jswaby’s picture

jswaby commented
Status: Active » Closed (fixed)

dr-xr-xr-x 2 jswaby pg527995 4096 Jul 22 20:58 .

it's the default directory that is not writable. change it to writable and delete the directory.

michaels-musings.com’s picture

michaels-musings.com commented
Title: Can't rm -r default/ » Make /sites/default directory writable again
Version: 6.x-dev » 7.x-dev
Category: bug » feature
Status: Closed (fixed) » Active

Hopefully I've gotten all this right to make this a fix for the 7.x branch.

The /sites/default directory in 6.x is non-writable, and as such causes numerous problems in addition to just not being able to remove it from the command line. Other issues include: can't reliable copy or make a backup of a site with CPanel, can't delete a site using CPanel, etc. Realistically most anything you would need to do to upgrade or test a Drupal site are impacted as normal means to create testbed areas from in-production sites don't currently work without the user resorting to the commandline.

The worst case problem seems to be a novice user trying to use CPanel to make a backup of their site. CPanel seems to indicate to the user it's copied all the files/directories correctly, but the contents of /sites/default are not copied.

Request: In D7.x make the /sites/default directory writable again.

mcrittenden’s picture

mcrittenden commented

Subscribe.

rupl’s picture

rupl
he/him
Primary language English
commented

Ran into the same problem trying to wipe my web directory clean on Dreamhost. To summarize the above posts, the problem was solved by executing two commands from the web root:

chmod -R 777 sites
rm -rf sites
mcrittenden’s picture

mcrittenden commented
Version: 7.x-dev » 8.x-dev
dibya’s picture

dibya commented

it is working . Thanks rupl.
dibya

jp_lew’s picture

jp_lew commented

Had the same problem until I read bboyjay's comment.

I went "chmod 777 default" and all was good. Thanks.

dibyadel’s picture

dibyadel commented

thaaks. It is working

pguillard’s picture

pguillard commented
Issue summary: View changes
Status: Active » Closed (won't fix)
pfrenssen’s picture

pfrenssen
Location Sofia
commented

Hijacking this issue since it is appearing as the top search result when looking for the way in Drupal 8 to make the sites/default folder temporarily writable on development machines.

This can be done by enabling the development overrides in example.settings.local.php and making sure the following setting is enabled:

$settings['skip_permissions_hardening'] = TRUE;

See the documentation in example.settings.local.php for more information.

For reference, this functionality was developed in #1232572: Add a variable to disable fixing file permissions during system_requirements() "runtime" checks and added in commit 854898258d67ab.

pfrenssen’s picture

pfrenssen
Location Sofia
commented
Status: Closed (won't fix) » Closed (duplicate)

Changing status from Won't Fix to Duplicate since this can be confusing. In the meantime this has been actually fixed. See my previous comment for details.