yeah, I thought about that

netsperience — Fri, 27 Jun 2008 20:23:14 +0000

yeah, I thought about that kind of test

point is, got the self-delete tool up and working on the live sites, don't need to fuss much here on dev

as long as I don't have other problems with permissions

Warning: there are naked butts on these sites, some chests, too. not quite pornographic- the large user base indicates they seem to fill a valuable societal function... from an anthropologist's point of view - from a programmer's point of view they serve a valid financial function

SO I guess the correct path

greg — Fri, 27 Jun 2008 16:22:00 +0000

SO I guess the correct path for this image on dev would be something like
/var/www/vhosts/dev/httpdocs/Kevin.jpg

Have you tried a test text file, rather than image, and see if you can fopen and write to it and delete it?
FTP a file like "test.txt" and try it, rather than use fopen to create it.

my delete script works on

netsperience — Fri, 27 Jun 2008 15:24:20 +0000

my delete script works on the live sites where images were created with php

it would be nice to work on dev sites but not essential...

there are a few contiguous

netsperience — Fri, 27 Jun 2008 14:30:37 +0000

there are a few contiguous situations going on here

1) images on live site are uploaded with php by users but directory is owned by root (is there a way to change that?)

2) dev site images are copied by ftp and not owned by root but also not created with php, uploaded in bulk with ftp

3) test image Kevin.jpg was uploaded by ftp

what about setting permissions with

for i in `find /var/www/vhosts/[DOMAIN] -type d $ -name 'http*docs' -o -wholename '*/http*docs/*' $ -print`; do setfacl -R -m (user|group):[USER/GROUPNAME]:rwx $i; setfacl -d -m (user|group):[USER/GROUPNAME]:rwx $i; done

As the error is permission

greg — Fri, 27 Jun 2008 10:14:43 +0000

As the error is permission denied... how do you upload the image "Kevin.jpg" in the first place?

If you use a HTML and PHP file upload form then it will be PHP that has permissions on the file and thus PHP will also have permission through your on-site files to delete it.

If you just FTP the "Kevin.jpg" and then try to delete it via on-site scripts with PHP then it is likely that PHP will not have permissions.
I would guess the file is owned by root, and therefore PHP wont have delete permissions .

So if you have been FTPing it, try using a file upload form on-site then try the exact same delete script you have been using.

Response from RackSpace

netsperience — Fri, 27 Jun 2008 03:28:20 +0000

Response from RackSpace about not being able to delete images on live sites - not even with ftp client which method does work on dev subdomains.

2 questions:

1) Where do I find the ACLs in Plesk?

2) Does it seem that changing permissions by the command line code below will enable a generic user/member to delete their own files by loading a php page in the browser? (this is intended to be a self delete tool - with ample warnings)

oh yes fyi I am logging in with ratebutt for ratemybutt.com -- and devadmin for dev.ratemybutt.com that username was set up by server admin - so for the dev sites there is either another user "dev" or support just made a mistake here.

Hi Randall,

What user are you logging in with? Since those files and directories are owned by root by default, you won't be able to modify the permissions on those files or directories unless you log in via SSH and become the root user.

I see that the user account 'ratebutt' has full permissions for ratemybutt.com's httpdocs and 'dev' has full permissions for dev.ratemybutt.com's httpdocs. I also see that someone has set up ACLs on the dev.ratemybutt.com httpdocs, but not for ratemybutt.com.

Rackspace doesn't support custom permissions for Plesk. Due to the way Plesk sets up domains, the only supported option is to use the FTP user that is created for a given domain. While this is a very common request from others using Plesk, we can't promise that these custom permissions won't break the functionality of your sites. Plesk does the permissions as it was designed and deviations from that pattern carries a risk of breaking things.

With that said, I have a command you can run that will setup ACLs to give a user or group full read/write access to files and read/write/execute access to subdirectories of httpdocs and httpsdocs.

for i in `find /var/www/vhosts/[DOMAIN] -type d $ -name 'http*docs' -o -wholename '*/http*docs/*' $ -print`; do setfacl -R -m (user|group):[USER/GROUPNAME]:rwx $i; setfacl -d -m (user|group):[USER/GROUPNAME]:rwx $i; done

That won't work if you just past it onto a command line and run it. The command will need to be run by the root user and there are several modifications you will need to make.

First, you'll need to replace [DOMAIN] with the domain you need to apply the ACL to, such as ratemybutt.com. Next, you'll need to change both instances of (user|group) to either user or group, depending on whether the ACL is being added for a user or a group. Finally, you'll need to replace [USER/GROUPNAME] with the name of the user account or group the ACL is being added for.

I give you this command so you can take care of the permissions yourself and have it for future use. As you have seen, any time you create a new domain, you have to manually modify the permissions. Also, since this is unsupported by Rackspace, you could be asked to pay our billable support fee of $75 per half-hour if you get a technician that has adequate expertise and the availability.

I would be more than happy to run that command for you this time, but I would like to show you how to do it yourself so you aren't faced with additional support fees sometime in the future. I will just need to know the username or group you need the ACL created for.

Please let us know how you would like to proceed. We look forward to hearing back from you!

Regards,

Daniel Givens, RHCE
Linux Administrator II
Rackspace Hosting

and this is my ticket opener:

Randall Goya said:
2008-06-26 16:50:16 (UTC-4)

I have tried manually deleting files in this directory and subdirectories with ftp and with the php unlink() function.

I cannot access the directory in filemanager probably the large number of files makes it time out.

I get an access denied or permission denied message when I try to delete the files.

It is not a protected directory.

The permissions chmod are set to 755 when I try to change to 777 I am not allowed.

I am able to change permissions on same directory copied to dev.ratemybutt.com to 777 but the ftp client also stops before all permissions are changed.

My goal is to delete the files selected by a database query on the user_id and delete/unlink the selected files with php code. There may be a file with the same filename in each of the subdirectories (different sizes) I have the php code written to handle it but cannot execute it.

I do not understand why the directory "new_images" in domain ratemybutt.com appears to have some kind of protection or lock I cannot find in Plesk.

well, it seems I am neither

netsperience — Fri, 27 Jun 2008 03:04:01 +0000

well, it seems I am neither stupid nor crazy (we shall see...)

I thought using filesystem path may be correct, but still get the error generated by the if...else statement in the code:

Error deleting /var/www/vhosts/dev.ratemybutt.com/httpdocs/Kevin.jpg

using $file1 = $_SERVER['DOCUMENT_ROOT']."/Kevin.jpg";
generates the identical error:

Error deleting /var/www/vhosts/dev.ratemybutt.com/httpdocs/Kevin.jpg

Yes, it is a subdomain, created on server by server admin, client has Plesk cp, not so great for creating subdomains - I requested single ftp account access to the 4 related subdomains (there are also dev.ratemybooty.com dev.ratemychest.com dev.howdrunk.com that share the same image dirs and db on dev.ratemybutt.com ) It took some time to get everything working, server admin had to add conf files for dev.ratemybooty.com dev.ratemychest.com to appear...

I am using the following .htaccess file, it is necessary for members' profiles to display:

Options +FollowSymLinks
RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/]+)$ http://dev.ratemybutt.com/index.php?option=profile&username=$1&task=$2 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/]+)/$ http://dev.ratemybutt.com/index.php?option=profile&username=$1&task=$2 [L]

I ran phpinfo() in the same dir as the delete_account.php file and image file (attached)

here's the last few entries in error.log:

[client 67.83.143.95] PHP Warning:  unlink(/var/www/vhosts/dev.ratemybutt.com/httpdocs/Kevin.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 24
[client 67.83.143.95] PHP Warning:  unlink(/var/www/vhosts/dev.ratemybutt.com/httpdocs/Kevin.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 26
[client 67.83.143.95] PHP Warning:  unlink(/var/www/vhosts/dev.ratemybutt.com/httpdocs/Kevin.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 26
[client 67.83.143.95] PHP Warning:  unlink(/var/www/vhosts/dev.ratemybutt.com/httpdocs/Kevin.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 28

earlier log with filename (in same dir) no path:

[client 67.83.143.95] PHP Warning:  unlink(Kevin.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 24
[client 67.83.143.95] PHP Warning:  unlink(Kevin.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 24
[client 67.83.143.95] PHP Warning:  unlink(Kevin.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 24

and here is even earlier log of trying to delete actual images in 5 directories:

[client 67.83.143.95] PHP Warning:  unlink(new_images/thumbnails/091207065141.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 41
[client 67.83.143.95] PHP Warning:  unlink(new_images/smallsize/091207065141.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 50
[client 67.83.143.95] PHP Warning:  unlink(new_images/midsize/091207065141.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 59
[client 67.83.143.95] PHP Warning:  unlink(new_images/original/091207065141.jpg): Permission denied in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 68
[client 67.83.143.95] PHP Warning:  unlink(new_images/091207065141.jpg): No such file or directory in /var/www/vhosts/dev.ratemybutt.com/httpdocs/delete_account.php on line 77

I also tried putting full

pr0gr4mm3r — Thu, 26 Jun 2008 23:59:49 +0000

I also tried putting full url http://dev.ratemybutt.com/Kevin.jpg but does not delete.

When managing files in PHP, you should use the filesystem path, not the URL. So, it would be something like "/home/user/public_html/image/directory/Kevin.jpg".

If you aren't seeing any warnings, make sure you have error reporting enabled.

If the file's set to 777

greg — Thu, 26 Jun 2008 23:23:39 +0000

If the file's set to 777 then unlink should work.
Does PHP return any errors?
Like - blah...No such file or directory...blah

The only thing I can think of is an incorrect path. Perhaps something to do with your server config and/or the fact it's in a sub-domain.

I say that because if the PHP script is in the same dir as the image, you have the correct filename and it is 777 then there should be no reason for it not to delete the file, regardless of the file type.

You could try

<?php
 $file1 = $_SERVER['DOCUMENT_ROOT']."/Kevin.jpg";
?>

But I am truly throwing guesses at you here, and you should be looking at the error log (if there is no on-screen reporting)