Unable to delete sites/default/* when uninstalling Drupal 6
mdlueck - September 1, 2007 - 02:24
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | install system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
Jump to:
Description
I can not figure out what Drupal 6 did to these files. I was testing Drupal 6, decided to uninstall it. These are the only two files I am unable to clean up. Most annoying.
I have installed / reinstalled / removed Drupal 5.x many times, and have not run into this sort of thing with Drupal 5.x.
u40009095:~/sites/test.org/www/sites/default > ls -al
total 24
dr-xr-xr-x 2 u4000909 ftpusers 4096 Jul 18 07:43 .
drwxr-xr-x 3 u4000909 ftpusers 4096 Aug 31 21:58 ..
-rwxrwxrwx 1 u4000909 ftpusers 6418 Jul 27 11:03 default.settings.php
-rwxrwxrwx 1 u4000909 ftpusers 6430 Jul 18 07:43 settings.php
u40009095:~/sites/test.org/www/sites/default > rm -f *
rm: cannot unlink `default.settings.php': Permission denied
rm: cannot unlink `settings.php': Permission denied
u40009095:~/sites/test.org/www/sites/default >
#1
How about permissions on the directory 'default'?
#2
Not sure anymore... I contacted tech support at my hosting provider to get the files blown away as I was thinking to install Drupal 5.2 on this domain again. Sorry.
I guess I could do a test installation of Drupal 6 current again and see if it happens again.
#3
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.
#4
In our case, the file seems to be owned by our userid at the hosting provider.
Good thought on rigging a method to have Apache delete the "undeletable" files. I will give that a try.
Except in this case both files seem to be under our userid's ownership: u40009095. (shrug)
I will plan on setting up Drupal 6 soon, see if it happens again, etc... If it does, it is a rather nasty difference between Drupal 5 and Drupal 6, and likely to become a support nightmare of sorts.
#5
Reinstalled, same thing, can not delete those two files...
The as-is perms are as follows:
u40009095:~/sites/test.org/www > ls -altotal 32
drwxr-xr-x 5 u4000909 ftpusers 4096 Sep 5 15:52 .
drwxr-xr-x 5 u4000909 ftpusers 4096 Jul 30 21:09 ..
-rw-r--r-- 1 u4000909 ftpusers 3436 Sep 5 15:39 .htaccess
drwxr-xr-x 2 u4000909 ftpusers 4096 Mar 15 2006 cgi-bin
drwxr-xr-x 2 u4000909 ftpusers 4096 Feb 23 2007 graphics
-rw-r--r-- 1 u4000909 ftpusers 0 Mar 15 2006 index.html
-rw-r--r-- 1 u4000909 ftpusers 779 Aug 31 21:53 php.ini
-rw-r--r-- 1 u4000909 ftpusers 26 Aug 8 22:34 robots.txt
drwxr-xr-x 3 u4000909 ftpusers 4096 Sep 5 15:51 sites
u40009095:~/sites/test.org/www/sites > ls -altotal 12
drwxr-xr-x 3 u4000909 ftpusers 4096 Sep 5 15:51 .
drwxr-xr-x 5 u4000909 ftpusers 4096 Sep 5 15:52 ..
dr-xr-xr-x 2 u4000909 ftpusers 4096 Sep 5 15:41 default
u40009095:~/sites/test.org/www/sites/default > ls -altotal 24
dr-xr-xr-x 2 u4000909 ftpusers 4096 Sep 5 15:41 .
drwxr-xr-x 3 u4000909 ftpusers 4096 Sep 5 15:51 ..
-rw-r--r-- 1 u4000909 ftpusers 6836 Aug 28 07:42 default.settings.php
-r--r--r-- 1 u4000909 ftpusers 6849 Sep 5 15:41 settings.php
I changed the perms on the files, still can not delete them...
u40009095:~/sites/test.org/www/sites/default > chmod 0777 *u40009095:~/sites/test.org/www/sites/default > ls -al
total 24
dr-xr-xr-x 2 u4000909 ftpusers 4096 Sep 5 15:41 .
drwxr-xr-x 3 u4000909 ftpusers 4096 Sep 5 15:51 ..
-rwxrwxrwx 1 u4000909 ftpusers 6836 Aug 28 07:42 default.settings.php
-rwxrwxrwx 1 u4000909 ftpusers 6849 Sep 5 15:41 settings.php
u40009095:~/sites/test.org/www/sites/default > cd ../..
u40009095:~/sites/test.org/www > rm -rf sites/
rm: cannot unlink `sites/default/default.settings.php': Permission denied
rm: cannot unlink `sites/default/settings.php': Permission denied
rm: cannot remove directory `sites/default': Directory not empty
rm: cannot remove directory `sites': Directory not empty
So, it seems to be a Drupal 6 thing. Most annoying! ;-)
#6
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
#7
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.
#8
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.
#9
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!
#10
JirkaRybka: You seem to have noticed the critical thing...
u40009095:~/sites/test.org/www > chmod -R 0777 sites/u40009095:~/sites/test.org/www > rm -rf sites/
u40009095:~/sites/test.org/www >
SUCCESS!!!
I will do one more test install to make sure it really works. Stay tuned...
#11
I just did a test install of Drupal 6 Beta 1 and indeed the above workaround solves the cleanup problem. Maybe it belongs in an FAQ somewhere???
#12
mdlueck, that worked for me... I was having the same issues people were talking about here.
#13
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.
#14
Thank you.
As our hosting provider is a large one, I assume they lock down the SSH accounts as best they can. I dare say we are not running around with group "nobody" or the like. Also they seem to utilize a multi-tear hosting architecture. The box we SSH/FTP to is a different one than Apache sits on. (Different kernel string and version).
If we did not have a package with SSH (*gasp!!!*) then I assume using an FTP client to manually adjust the perms of files to 0777 would be equally successful.
BTW: If you untar the Drupal installation files on the server and them "rm -rf" it will successfully delete all of the files. Just when the installer has been run, and the installer modifies the perms of files in the sites/ directory.
All files show up as being owned by our SSH ID. Even when we unpack the Drupal tar file, the server sets our ID as the owner of the files.
#15
I just noticed one error in what you wrote. I issued a chmod, not chown / chgrp.
#16
Shouldn't this be a bug report? If the install system creates a directory or file then there needs to be an uninstall system to remove them since the owner of those files ends up being the web server user and as is being discussed there might be some users who would be left with the inability to easily remove all of the package.
#17
And it then becomes an install system issue.
#18
Refer to comment #15...
I did not chown / chgrp. I was still the owner of the files in question.
#19
@mdlueck: I don't understand what you're trying to say. If the web server creates the directory then the directory is owned by the web server user. If I as web administrator then try to remove the entire installation then that directory isn't removable by me without becoming root. If I can then there is a bug with the OS or there is some privilege given to the web administrator that isn't normal.
#20
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.
#21
@Arancaytar: Some !== all. The issue still exists.
#22
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.
#23
@Arancaytar: Sorry, I thought you were putting up an argument by beginning with
I understand what you were trying to tell me now.
#24
@Arancaytar: My hosting provider does run PHP as a CGI, and they give a choice of 4.x or 5.x I am guessing by the fact that they run it as a CGI that is even an option.
From time to time at another provider one client was hosting at, files ended up root:root from time to time, and it was necessary to work through those issues with the hosting support people. This provider did run Apache as a mod. Maybe the difference is that our current provider does run it as a CGI rather than an Apache mod.
#25
You basically need to figure out how you can remove webserver created files -- ask your ISP. This is not a bug.
#26
No! If Drupal creates the file system then Drupal needs to remove it with an uninstall Drupal option. Also, in that uninstall option all (core and contrib) Drupal database tables created need to be removed.
#27
I agree that it isn't a bug, per se, it is more a feature request.
#28
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
#29
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.
#30
0755 works fine also for me, thx :-)
hosting: web4u.cz
http://www.krizak.cz/phpinfo.php
#31
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?
#32
ximo: Sounds like the correct way to go. I would suggest that symlink paths not be followed but the symlink removed. I would also suggest that only the default DB connection tables be removed and not named DB connections.
#33
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.
#34
jonfhancock: Your battle stories are much worse than mine! I think it will be a long LONG time before I think about moving from my current hosting provider! They run PHP as a CGI, and support two PHP versions - PHP 4.x by default, and you can specify PHP 5.x for the entire site.
At another provider that ran PHP as an Apache mod, I kept running into files that I could not delete. It has been a while, but I think certain files ended up root:root. (head shaking) NO GOING BACK! ;-)
#35
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.
#36
@ 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
defaultfolder, 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?#37
Settings.php does not delete, even if I CHMOD sites or default folder to 755, settings.php still won't delete.
#38
@Joining: If you don't own settings.php (probably owned by the Apache user) then you need to
chmod 777 sites/default/settings.phpto give full privilege to the file. Then you should be able to remove it.Yes, there are other ways to do it; but we are really interested in just getting rid of the file.
Caveat: I am assuming that you have standard UNIX ACL and there are not added security features that may also prevent you from removing a file.
#39
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:
<?phpchmod("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.
#40
#9 Thanks a lot !
#41
Marking as duplicate of http://drupal.org/node/225880 which should fix this issue for new installs.
#42
See also these PHP snippets which can be used: http://drupal.org/node/34028
#43
@7 works.