cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to delete files

N/A

Unable to delete files

I have a classified ads programme running on my site. Part of the appeal is that visitors can upload pictures of the items they have to sell. The ads are auto deleted after 21 days but the pictures are not. I am unable to manually delete them myself as I receive the error: 550 permission denied. What is likely to be causing this error? I can't keep going to support to have them removed as they get a bit p*ssy about doing it, but the files are mounting up and consuming valuable space.

Thanks for any suggestions.

Mark
4 REPLIES
N/A

Unable to delete files

The problem is that the files were created by the web server (which I believe now runs as user "wwwuser" or something similar -- it used to be the user "nobody") not by you, so your permissions with respect to these files are fairly limited.

Take a look through the topic Attributes of Files Owned by "nobody", which identifies some tools which may still be useful in helping you. (They were written in the days when the web server ran as "nobody", but I think they should still even though it now runs as a different user -- you should be able to use it to deal with files owned by "wwwuser" (or whatever it now is), but if you still have files created by the web server from its "nobody" days, then you will have to ask Support to mop those up.)
N/A

Unable to delete files

Hmmm, but the problem will exist every time the script I use sends a file to the server Sad . As the files it sends are pictures, it builds up quite steadily. The whole folder (which I created and originally chmoded to 777) now cannot be deleted, neither can the files within obviously.

I suppose the major question is why has ownership of the folder changed from belonging to me to belonging to the server? I also have this problem with ikonboard which I cannot uninstall from the server. I did ask support to remove it which they told me they had done....... Butit is still there!

I can't use the tools mentioned by Task because I don't know how to use php.

Cheers

Mark
N/A

Unable to delete files

If your script is run by the web server, then any files it creates are owned by the user -ID under which the web server runs, which as far as I'm aware is now wwwuser.

To delete an object (be it a directory or a file) you need write access to the directory which contains the object -- you do not need write access to the object itself. The same applies to creating an object. Creating or deleting an object requires an entry to be added to, or removed from, the directory which contains it, so you must have the ability to modify that directory (ie write access). You do not need write access to the object itself (which, for a file, gives the right to change the file, and for a directory gives the right to add or remove entries).

How your directory has become owned by the web server (or the web server's user-ID) I do not know: if the directory was created by you (not via a script run by the web server), then only someone with root access could change ownership.

As far as the "nobodyTools" (which should probably now be renamed to "wwwuserTools") are concerned, you do not need to know "how to use PHP" any more than you need to know "C" to run Linux or Windows. You simply unpack the tools using the "tar" command (make sure it is outside the cgi-bin directory, which is for perl scripts), and then point your browser at the permissions.php file. If you put the nobodyTools.tar.gz package in your home directory, after the tar extraction you will have a subdirectory called nobodyTools and inside that will be a file called permissions.php.

You should then start your web browser, and enter the following in the address bar:
    http://cgi.username.force9.co.uk/nobodyTools/permissions.php
    (replace username with your username)
Your browser should then display a screen entitled "PHP File and Directory Permissions", the top part of which looks like this:


The top of the permissions.php screen [Click for larger picture]

There is a text-entry box in which you supply the name of the object you wish to process, which can be a file or a directory. The object is assumed to be in your CGI space, so the first part of the path is already completed, leaving you to complete the rest.

Underneath this, there are selection boxes to allow you to modify what is processed, and how much output is produced:
  • The Single-Item option is only applicable if the object you entered is a directory. The normal processing of the program is that if the named object is a directory, then it will process both the directory itself and all its immediate subordinates (ie the files in the named directory and any subdirectories, but not the contents of the subdirectories). However, if all you want is for the named directory to be processed, but none of its contents, you should select the Single-Item option.

    In the case of the named object being a file, that file will always be the only object processed, regardless of which options are selected.

  • Recurse. Again, this option only has effect if the named object is a directory. By specifying this option, in addition to processing the directory and its immediate contents, the contents of any sub-directories will also be processed.

    If both Single-Item and Recurse are selected, then Single-Item takes effect, and Recurse is switched off.

  • Verbose. With this option selected, the program will report back on every object it encounters. If it is not selected, the program provides basic information plus all exceptional matters (eg, if it cannot change the permissions of an object -- generally because "nobody" does not happen to be the owner of that particular object [ie, it is an object you already own]).
When you are happy with the settings, press the "Perform Processing" button.

A "Processing Report" segment of the page will now show beneath the "Processing Parameters" segment. From this you should be able to determine if all went well, or whether there were significant errors. Normally, objects which could not be processed are ones you already own, so it does not matter that their permissions could not be changed.


The Processing Report part of the permissions.php screen [Click for larger picture]

If there are further objects to be processed, repeat the process.

As a result of changing the permissions, your user-ID should then be able to remove the unwanted entries. The "nobodyTools" package contains a shell script which can assist you in doing this, or you can simply do it manually if you prefer.

The best way of dealing with directories owned by "wwwuser" is to make sure all the permissions of subordinate objects are satisfactory (as described above by using permissions.php), to identify the highest level directory owned by "wwwuser", and then just do a full directory copy of that directory, followed by a delete of the "wwwuser" directory, and a rename of your copy.

For example, if "someDir" is a directory containing other objects (files and sub-directories) at least some of which are also owned by "wwwuser", you could proceed as follows:[list=1]
  • Copy the entire directory structure including all the subordinate objects (the -R option on the "cp" command causes the copy operation to recurse down the directory structure):
    cp -R someDir copyDir

  • Remove the entire original directory. Do this only if the cp command did not give any error messages!:
    rm -rf someDir

  • Rename ("move") the copied directory to the original name:
    mv copyDir someDir[/listShocked]Because you will have created all the objects in the copied directory you will be the owner of each one; thus, by then removing the original directory and renaming your copy of it to its original name, you will have gained control of both it and all its objects.
  • N/A

    Unable to delete files

    Cheers Task. I managed to remove the pictures with the programme, superb. Didn't have to do all of what was said in the tutorial though, only process the folder! Still don't appear to be able to remove ikonboard though, that'll have to wait for another day.

    Cheers

    Mark