Drupal on Ubuntu Karmic 9.10 reacting badly to the fuse mount files directory, saying Tmp directory not properly configured.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Mount an s3 bucket at sites/default/files with -o allow other
2. When I clear the caches in Drupal, I get the message: The selected file 
/tmp/filetpCouI could not be uploaded, because the destination is not properly 
configured.
3. My drupal tmp directory goes nuts, locks up, because of the fuse "foreign" 
s3fs directory.

Also, the sites/default/files directory & corresponding bucket are sloppy. 
Folders are created, but files aren't inserted into them, rather they all stay 
in root folder together.

Thanks so much,

Joseph

Original issue reported on code.google.com by jsh...@gmail.com on 16 Jun 2010 at 11:35

[GoogleCodeExporter]

For anyone with the same problem, now that my issue is solved, here's what I 
did: Create a directory for s3 in the mnt directory and create a symlink to 
sites/default/files. (Don't try to make a fuse mount directory outside the mnt 
directory.) 

Original comment by jsh...@gmail.com on 22 Jun 2010 at 8:21

[GoogleCodeExporter]

Hi Joseph,
I've been researching using s3fs to replace the files directory in my drupal 
installs. Have you run into any other issues or has your strategy using the sym 
link cleared everything up?

Thanks,
John

Original comment by JohnnieH...@gmail.com on 23 Nov 2010 at 6:52

[GoogleCodeExporter]

Hi John, everything's been fine...my later issues have been related to 
integrating some amazon web services tools through cloudfront module etc. and 
also auto-scale for ec2...but as for drupal itself, it's been really good, 
behaving well...so go for it.

Original comment by jsh...@gmail.com on 23 Nov 2010 at 6:55

[GoogleCodeExporter]

Hello Joseph, I'm having the same issue of the files sitting in the root 
folder.  However, I have the drive mounted in mnt and then symlinked to 
sites/default/files.  Just wondering if you know of another reason why that 
happens.

Thanks,
Ray

Original comment by raystu...@gmail.com on 25 Nov 2010 at 2:57

[GoogleCodeExporter]

Hi Ray, after I symlinked in sites/default/files, the amazon bucket now does 
have proper directories...so i'm clueless as to why it's happening in your case.
Joseph

Original comment by jsh...@gmail.com on 25 Nov 2010 at 3:32

[GoogleCodeExporter]

Is this still an issue? If so, please provide specific details on how to 
reproduce this.  ...assume that I dont' know what Drupal is.

Original comment by dmoore4...@gmail.com on 30 Dec 2010 at 4:18

[GoogleCodeExporter]

it's still an issue...basically install your cms (drupal) in your www directory 
and then symlink its file system to an s3 mount thusly: mount the mnt/s3 
directory to the appropriate amazon bucket. create a symlink to the drupal 
var/www/sites/default/files where files are stored so that amazon can take them 
off your app server's hands, and then a symlink to var/www/tmp so that drupal 
can write a little tmp file when certain events occur, such as a cleared 
cache...the second tmp symlink comes up as being a permissions issue even when 
properly mounted, even when writable...drupal will throw an error that it isn't 
writable. i've gotten it to work with a couple installations, but each time i 
install a new site, i bump into this issue. i believe someone once suggested 
chgrp www-data as a possible solution for tmp directory, but strangely even 
when the tmp directory is fully 777 www-data writable and files are saved 
properly, drupal doesn't seem to think so, and says not properly configured.

Original comment by jsh...@gmail.com on 30 Dec 2010 at 7:42

[GoogleCodeExporter]

okay, i got to the root of the problem & realized it was one of my drupal 
modules causing it, and not drupal core itself...i tweaked a few settings  in 
the module & tmp problem went away. hopefully this will remain so for all 
future installations...

Original comment by jsh...@gmail.com on 11 Jan 2011 at 9:27

[GoogleCodeExporter]

If I interpret this correctly, this is a use model issue and not a problem with 
s3fs itself.  Marking this one invalid and closing it. If it is found that this 
issue was caused by a defect within s3fs itself, please feel free to reopen 
this issue or open a new one.

Thanks for getting to the bottom of this, I didn't relish the thought of trying 
to reproduce. ;)

Original comment by dmoore4...@gmail.com on 11 Jan 2011 at 11:27

• Changed state: Invalid

[GoogleCodeExporter]

Glad I got to the bottom of it too! The only thing i haven't solved is why 
little files keep getting created on s3 that accompany and share the same names 
as each directory created...sort of like having a bit of trash in each 
folder...anyway, as long as it's functioning properly, i really don't mind 
having a few extra bytes hanging around :)

Original comment by jsh...@gmail.com on 11 Jan 2011 at 11:34

[GoogleCodeExporter]

That's not a bug (the small files), it's a feature.  This is how s3fs 
represents directories.  You must be referencing the bucket from another S3 
client?  All of these files should be zero length.  Don't delete them or you'll 
be in trouble when it comes to your s3fs-mounted file system.

This representation of directories is part of the original design.  S3 buckets 
themselves really don't have directories (although it may appear so through 
other clients).  

Original comment by dmoore4...@gmail.com on 12 Jan 2011 at 12:09

[GoogleCodeExporter]

so glad to know that, i won't delete them!

Original comment by jsh...@gmail.com on 12 Jan 2011 at 12:17