cancel
Showing results for 
Search instead for 
Did you mean: 

Locked files

N/A

Locked files

I have a directory in my CGI space that I cannot delete.

I am aware that there are hidden files in it and can view these using -al through WS_FTP however when I try and change the permissions on these files (.htaccess and others) I get 'permission denied'.

Any ideas?
10 REPLIES
N/A

Locked files

I had this problem, it would seem that they will be owned by the server (not sure why) and not you. I can't remember what the code to telnet in to the server is (Colin did tell me in an earlier post but I can't find it), but if you do this, you will be able to see who the owner is.

If you can't do that otr the files are indeed owned by the server, you will need to raise a ticket and ask CS to delete them for you.

Cheers

Mark
N/A

Locked files

Thanks Mark, that is very helpful, I will give it a go

Cheers
Chris
N/A

Locked files

ls -l will tell you more info.

You could just write a little script which runs rm <exact path to file name>, and then call it via the web... but you wouldn't want to make a mistake, if you catch my drift.
N/A

Locked files

I had this problem - still do actually, and with many little chats with the service/support team, f9 are now looking into the issue for me, as I could not get rid of them by telnet or ftp, nothing would work. they have said they have been locked on the server side of things so they are going to delete them for me. May be worth contacting f9 as well about this/
N/A

Locked files

also had files and folders on the cgi webspace which i too could not delete for some reason after uploading files
N/A

Locked files

Task posted a link to one of my queries for some tools to help change permissions and delete files. It is: http://cgi.didit.force9.co.uk/nobodyTools/permissions.php

It doesn't work with all files though, I still had to get CS to delete ikonboard files (eventually!!)

Regards

Mark
N/A

Locked files

Which user was the owner of the ikonboard files? Remember, the user associated with the web server has been changed in recent months, so if your ikonboard files were created by the web server running under its original user name ("nobody") then the files will have been owned by "nobody", and the web server, running under its new username, "wwwuser" will not have the authority to change permissions.

Any files created by the web server now will be owned by "wwwuser", and the web server will have the right to change their permissions, so the "permissions.php" script, as supplied in the package, should work satisfactorily with these files (or directories).
N/A

Locked files

Not quite true.

Nobody and wwwuser are the same uid according to Ben, so files owned by nobody should have automatically become owned by wwwuser...
N/A

Locked files

I wasn't aware of that, Colin -- in fact, I only knew the user name had changed as a result of reading one of your posts! -- but I understood there to have been good reason to make a change, so I'm surprised to hear it's essentially cosmetic.

I've just checked, and it seems to me they are quite distinct:
    task@cgi03 task $ id nobody
    uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
    task@cgi03 task $
    task@cgi03 task $ id wwwuser
    uid=99(wwwuser) gid=99(wwwuser) groups=99(wwwuser)
    task@cgi03 task $
N/A

Locked files

Yes, nobody still exists, but they webuser isn't running as that userid any more. I can't comment on the F9 Shell server, but certainly on the PN one, all the files owned by nobody are now owned by wwwuser...