Unable to delete sites/default/* when uninstalling Drupal 6

How about permissions on the directory 'default'?

Another tip, just to say all I have: If unable to access as root user (remote hosting), I usually remove such files with small temporary php scripts. If the file was created by user Apache (Drupal), then it's easiest to remove also as user Apache. There are quite a few useful scripts around the web, somewhere I even found automated php-tool for whole directory-tree removal.

As for Drupal 6, I also see a problem on my local machine: The file settings.php is created by Drupal (from default.settings.php), so owner of the file is Apache process, and I'm unable to delete it. Testing the install process multiple times, I removed temporarily by renaming parent directory and create new one, later logging in as root user and cleaning up... But this seems to be a different issue, and is no bug - the file SHOULD be protected due to security matters.

i also thought i would try out drupal 6 and now can not delete these 2 files. i changed all permissions and it still says permission denied when i try to delete the files. i have managed to change the directory names, but those 2 files still can not be delete. any idea how i can do this? thanks

Looking at the listings above, I noticed that the 'default' directory itself is not writable (which really IS attempted to set this way in the code!), so you should probably CHMOD also the 'default' directory, not only just files inside.

In my case, unfortunately, I'm not owner of the file 'settings.php' (owner is Apache = Drupal scripts), so I can only remove it as root user, or via small php-script.

Using a hosts admin panel, or file manager they delete fine.

I'd have to test this again, but It seems they delete, if the DB tables are removed first.

I can't find the source of this anymore, but still have the helper script on my system:

<?php
// ggarciaa at gmail dot com (04-July-2007 01:57)
// I needed to empty a directory, but keeping it
// so I slightly modified the contribution from
// stefano at takys dot it (28-Dec-2005 11:57)
// A short but powerfull recursive function
// that works also if the dirs contain hidden files
//
// $dir = the target directory
// $DeleteMe = if true delete also $dir, if false leave it alone

function SureRemoveDir($dir, $DeleteMe) {
    if(!$dh = @opendir($dir)) return;
    while (($obj = readdir($dh))) {
        if($obj=='.' || $obj=='..') continue;
        if (!@unlink($dir.'/'.$obj)) SureRemoveDir($dir.'/'.$obj, true);
    }
    if ($DeleteMe){
        closedir($dh);
        @rmdir($dir);
    }
}

//SureRemoveDir('EmptyMe', false);
SureRemoveDir('/path_here/www/drupal/sites/default', true);

Just edit the path to match your system, place the whole inside some .php file, and open it from browser - it removes directories as Apache user, so will be able to remove what you can't (and vice versa). After use, immediately remove this .php file!

mdlueck, that worked for me... I was having the same issues people were talking about here.

I think some of the information herein isn't exactly correct.
mdlueck and others who are able to issue chown or chgrp from the command line directly are doing so with some kind of super-user power, or are at least using a user that is in the same group as the file. Note that it's possible that the shell access program was given high privileges or web server group privileges.

MisUnderstood says that it can be done from the file manager at cpanel (I'm paraphrasing), but that's true only if the hosting service gave super-user or at least web-group privileges to that file manager application (not unlike mdlueck getting those privileges when logging in for shell access).

Then, mdlueck uses a program that focuses on removing a directory that has hidden files. The "hidden files" part is only one aspect of what is happening here, the program will still run under the privileges of whomever ran it. If the program is running under apache, then it usually runs as user "nobody" and user "nobody" is typically given very few file system privileges.

Bottom line: I think you folks have found 3 ways that your hosting services have let you exploit SU or www-group privileges you probably shouldn't have been able to access. The rest of us might be left with undeletable files.

I'm working on a solution, but right now, I think this is a valid bug in 6.

Nope. Some hosts (Dreamhost, for example) run PHP as the normal user, not the Apache user. All files PHP then creates are owned and removable by the normal web admin.

But the behavior described by mdlueck is expected assuming that his server is configured like I said. This does not solve the issue, but it does explain what you did not understand in #19.

You basically need to figure out how you can remove webserver created files -- ask your ISP. This is not a bug.

set all to full permission site file and one by one whats in it then set default and settings php to 0755 and you can remove all of it one by one then when its empty worked your way back can delete the main one
worked for me

Features definitely (and bug fixes, in the first instance, for that matter) go in 7.x.

TBH the bigger problem is usualy the files directory, if subdirectories are created and owned by the Apache process you may not be able to remove them without either webhost intervention or a helper script.

0755 works fine also for me, thx :-)

hosting: web4u.cz
http://www.krizak.cz/phpinfo.php

Now that this is a feature request.. what about including an uninstall.php (for superuser only, like update.php) that completely removes Drupal from the webserver? One could even select which parts to keep, such as the /sites directory or the database tables. That would make it a breeze to uninstall Drupal. Or is this a horrible suggestion with regards to security?

This is broader than just uninstalling.

This is a bug with the Drupal 6 installer.

Since settings.php is owned by nobody, and read only. I can't edit it at all, either via SSH or a web interface.

So, say I want to install bjaspan's Persistent Login module. I have to edit session.cookie_lifetime to 0 in settings.php. That is not possible now, because I can't edit settings.php without getting tech support involved (I'm sure they're going to love that).

Also, the status report complains that sites/default/files is not writable. Unfortunately, since I don't own that directory, I can't change the perms. Then I have to go back the old school method of a files directory in the document root.

Seriously though, Drupal creates these files and folders in an effort to make installation easier for the average user. I can get around this, but the guy who walked off the street and decided to try Drupal probably can't.

This was a great idea, and is not a problem on dedicated servers, but for a shared hosting environment (and let's face it, that's the majority), this is a nightmare.

This doesn't need to be put off for 7.x, it needs to be fixed in 6.

I'm hosted at 1and1. I am new at Drupal and the entire LAMP thing. I am experimenting with Drupal and got to the point of removing the installation and re-installing (from scratch) only to be unable to delete the settings.php file. As pointed out by at least one person, I temporarily changed the permissions of the default folder to 755 and then I was able to delete the settings.php file. All is well now and I have a clean new installation with a new database.

@ jonfhancock #33:
You're right - there are modules that require you to alter the settings.php file, so this is beyond simply deleting the files. But this is also beyond fixing in D6. It would require a rewrite of the installation process into what we had in D5, which would be a step back in terms of usability. For D7 is possible, but I hope we can find another way to solve this..

@ magicflea #35:
I don't think what you describe will work for everybody. You would have to be able to chmod (change permissions of) the default folder, and a lot of shared hosts simply won't let you do that. Still, we should document this as a possible solution in the handbooks - if it's not already there?

Settings.php does not delete, even if I CHMOD sites or default folder to 755, settings.php still won't delete.

And if settings.php *is* owned by the webserver process you will probably need to use a PHP script (which would run with the user ID of the webserver/PHP user) in order to change the permissions on it (only the owner or root can chmod a file). (The other option is to ask your webhost for assistance.)

Create a new file called e.g. fixsettings.php something like this:

chmod("settings.php", 0666);

(or 0777) and visit www.example.com/sites/default/fixsettings.php. Or you might be able to use a PHP-based command line emulator like this http://mgeisler.net/php-shell and then run "chmod a+w settings.php" from the prompt.

#9 Thanks a lot !

Marking as duplicate of http://drupal.org/node/225880 which should fix this issue for new installs.

See also these PHP snippets which can be used: http://drupal.org/node/34028

@7 works.

#7 also worked for me. I have had several issues with this over time.

It is counterintuitive to think that changing the permissions, recursivel, on the parent directory, would then effect the permissions on the included files, when changing the permissions on those files directly fails. Nevertheless it does.

Example:

(in directory mysite.com)
chmod 0777 settings.php
rm -rf settings.php *fails*

from www (above sites folder)

chmod -R 0777 sites
cd sites/mysite.com
rm -rf settings.php *success*

Hi!
I am using Bluehost/Hostgator. I have discovered that if you login to your site using SFTP/SSH (I am using either FileZilla or WinSCP), you CAN change permissions that are denied using regular FTP.
I hope that this helps someone.
Regards,
Brian Brown, Ph.D.
brian(at)brianbrown.net

You can edit or delete these files using your cPanel's Legacy File Manager

Yeah, very weird.
777 did not work for me.
755 did. *scratches head*

I wasted around 2 hours to delete 'sites folder'. Finally, I have got a solution.

Need to follow these steps or contact to your Rental Server Provider.
Step 1. Create or install any new php applicaton in root or in a sub-directory. (In my case, I installed counter application through control panel (C-Panel) provided by my server provider.
Step 2. Re-login to FTP or refresh (F5) FTP.
Step 3. Delete sites folder.

If site is hosted on Bluehost:
Step 1. Give 777 permission to sites folder and subfolders.
Step 2. Delete sites folder.

Nihonsei

@7 worked for me

#7 worked for me too (needed to change permissions on default folder). Thanks!

#39 was a lifesaver! Thanks!

@7 That worked perfectly for me... Cheers!!!

#39 worked great for me! Thanks!

I managed to do it using filezilla by checking the "apply settings to all directories and files" and then deleting using filezilla.

If you are just trying to update the contents, you will find that using your File Manager provided by your ISP the easiest solution is to edit the contents, rather than deleting and replacing.

it is working perfectly to me otherwise I was struggling

Just started using D7 and my first istallation used the 'default' folder. Then I learned about multi site and created my 'example.com' folder where I installed the site again. Not needing the 'default' folder contents anymore I deleted it (apart of default_settings.php) but realised there not all is gone. An empty 'files' folder and 'settings.php' were still there, playing with permissions did not help. I went into searching drupal.org and unfortunately came across various threads related to D6 and Apache ownership of the files. This confused me even more. Ultimately it was the 'default' folder permissions that had to be altered, not just the permissions of files inside AS SUGGESTED BY #7

If you are using Drupal 7 it is likely this is your solution so don't waste time like I did :)

I had the same problem, very frustrating. I managed to delete the drupal folder from the c-panel by usling the Legacy File Manager - using this method also allows you to delete the file from "trash". It worked for me, good luck.

c-panel, Legacy File Manager worked for me too. Thanks, annam, for the tip!

ty! it worked!!! @39

Hi there,

Haven't bee through the whole threads list, but giving 777 to the whole sites/ directory including subfiles, then deleting files/directory worked for me.

Cheers.

Hi, I'm not a programmer but programming noob.

If this solution works as You write, can You write step by step where and how to put it?

"u40009095:~/sites/test.org/www > chmod -R 0777 sites/
u40009095:~/sites/test.org/www > rm -rf sites/
u40009095:~/sites/test.org/www >"

I tried Drupal 7.22 but the problem is exactly the same and now I'm blocked, I cannot delete files, I cannot instal Drupal.