directories created owned by web server

I also had the problem that i could not delete files belonging to userID apache.
I solved this problem with a tiny php program called filethingie.
It delets all files and directories and can be installed in public_html easily and safe if protected when not in use with 644.
Do this help you?

http://www.solitude.dk/filethingie/

Leo

Hello!

It is now hours that I am trying to solve this same problem ... Did you solve it?

The main issue is that I can't create a fileshare...
If I want to create a new fileshare called "upload" in the "files" folder (I give "files" as Node base path) Drupal creates the directory files/uploadxxx (e.g. files/upload128) but then the fileshare creation process is blocked and I get the error message:

DIRECTORY ERROR - please check "files/upload128/_previews".

The newly created directory "upload128" is owned by the user "apache" and have these permissions: rwx rwx r-x

Any idea how to solve this?!

Thanks a lot

Nadir

The directory permissions are being set to 2775 by fileshare. That's my understanding of how they should be set. Here is where they are set - line 283:

  if (!is_dir($node->_basepath.$node->_filepath)) {
    umask(0000);
    if(!mkdir($node->_basepath.$node->_filepath, 02775)) { // checks and writes directory
      die('DIRECTORY ERROR - please check that "'.$node->_basepath.'" is the correct path and that it is writable by your the webserver.');
    } else {
      drupal_set_message('Directory <strong>"'.basename($node->_filepath).'"</strong> created.');
      $thumbspath = $node->_basepath.$node->_filepath.'/_previews';
      umask(0000);
      if(!mkdir($thumbspath, 02775)) { // checks and writes previews subdirectory
        die('DIRECTORY ERROR - please check "'.$thumbspath.'".');
      } else { // both directories written
        drupal_set_message('Directory <strong>"'.basename($thumbspath).'"</strong> created.');
      }
    }
  }

There is the possibility of course to add a folder chmod permissions setting to the nodes... but would that be a good thing? I would think a lot of people wouldn't know what to do with that.... I guess I could have it default ...

Thoughts?

Jamie.

I'm experiencing something similar, where the permissions for the folder are being set as the appache web server, rather than user, and so I am unable to upload files into the folder manually through FTP! This is a pain as I want to upload files larger than 4mb (which is the limit through php)!

Has there been any further suggestions as to a fix for this?

Would it be possible to configure the module so that you can simply browse an existing folder, rather than always creating a new one? That would enable to me upload a folder with files, and then simply point fileshare to that, rather than fileshare creating a new folder!

I think that the reason for the 2775 is to allow the use of FTP to upload files into that directory. The '2' represents setgid (Set GroupID).

If the location for the 'files' directory has its owner set to the apache user (www-data on debian*) and the group set to a group that your FTP users belong to (say 'fsuser' for this example)..

~$ chown www-data.fsuser files
~$ chmod 2775 files
~$ ls -ld files
drwxrwsr-x  39 www-data fsuser 11168 Mar 9 14:55 files

When a directory or file is created under files/ it will receive the user permissions of the process creating that object, and the group of the parent folder:

Given a umask of 002

user@host ~$ mkdir files/Share
user@host ~$ touch files/Share/test.txt
user@host ~$ ls -lR files
drwxrwsr-x 2 user fsusers 72 2007-03-10 15:08 Share

files/Share:
-rw-rw-r-- 1 user fsusers 0 2007-03-10 15:08 test.txt

In this way apache has full permission to the tree, and a local (or ftp) user can still manage the files without the use of root or evil su tricks.

Depending on how things happenend and who ended up with owner and group at what level, this could adversely affect the behavior of the module.

If my thinking is correct, there may be situations where 2775 is appropriate in a suexec environment, but not everyone will have the level of control at the OS level needed to take advantage of this in the same way.

I think the addition of a perms config would resolve the situation, but at what granularity? I think only three or four possible options; root only, share, directory, and file. I would also assume the need for a configurable set of defaults in the case where users are allowed to create fileshares. A way of hiding the added "advanced" bits might be desireable as well.

Any thoughts?

Has there been any resolution to this issue?

@buggs_moran:
It's not likely that anything much will be done..

In the case that PHP runs as the apache user, just like with any other file storage operating in drupal, files will end up with permissions based on apache's user/group. The best thing you can do in this situation is use the set group flag on the files folder.

I the case that PHP runs as the user (suexec), this *should* work, files should not be owned as apache, and in fact it would be impossible for this to happen unless something either isn't working as expected.

My best suggestion is to read post 5 above, insure you know what user PHP runs as, and find a solution that will best work for you.