Err.. accidentally hit TAB and then space, resulting in the email being sent a little early. Anyway, here is the rest of what I was going to say:<br><br>Another way is to have Apache belong to your GID, but I doubt you'll get your hosts to manually do this. A far better solution is to run php-cgi, so apache runs PHP scripts as your UID and GID, so any files created by apache belong to you. You can also look into the suphp apache module, which basically does the same thing (
<a href="http://www.suphp.org/Home.html">http://www.suphp.org/Home.html</a>).<br><br>This problem is pretty common across many different php packages that allow users to upload files, not just Drupal.<br><br>-Victor<br><br>
<br><div><span class="gmail_quote">On 4/6/06, <b class="gmail_sendername">Victor Trac</b> <<a href="mailto:victor.trac@gmail.com">victor.trac@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="direction: ltr;">I think you're unfairly blaming Drupal for the configuration of
Apache/. The problem here is that Apache normally runs as separate user
who doesn't have write access to your files (rightfully so). When you are asking Apache to upload a file, it has to have write access to a directory in which to place the files. So then you end up with files in your home directory belonging to Apache that you have no write access to. Since the UID and GID of the uploaded files belong to Apache, you can't chown or chmod them (unless you're root). This has nothing to do with the Drupal scripts but the way Linux/Apache is normally configured.
<br><br>One way to get write access to the files that Apache creates is to belong to Apache's GID and have group permissions set to write. This isn't a good solution for hosts because then any user has write access to other users' apache created files.
</div><div style="direction: ltr;"><span class="e" id="q_10a6e58a66b25977_1"><br><br><div><span class="gmail_quote"></span>"Victor Trac" wrote:
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> A shot in the dark -<br>> I've never messed with the acidfree module, but I'm guessing Apache (it is
<br>> apache, right? :)) isn't running as your user, and ./private/filemanager.lck<br>> file isn't globally writable. Try chmod 777 ./private/filemanager.lck.<br><br><br>Simon, I've been having the same exact problems with 'attachment' +
<br>'filemanager' modules.<br><br>Drupal just has a very long way to go before it could really be considered<br>"friendly" for virtual hosting.<br><br>In your case, as in mine, the script(s) are designed to CHMOD the
<br>permissions on some files so that they are owned by 'apache' in the group<br>'apache'. (This means UID 'apache' and GID 'apache'.)<br><br>The problems caused by this are, as you've seen, problems in even running<br>
the modules at all, but the problems get worse.
<br><br>If you have any automated server/db backup scripts, they will fail also if<br>they don't have the correct permissions -- which they won't, in this case.<br><br>I would suggest that you (like me) find some other image uploading tool to
<br>use in conjunction with Drupal, and just stick with that.<br><br>I can not figure how a software like this has gone for so long without any<br>adequate image uploading capability.<br><br>Everyone seems to think "image galleries" rather than just "insert a
<br>flipping image into this content".<br><br>Anyway, using images in Drupal/CS content is real PITA and these permissions<br>errors are as well.<br><br>I had to spend several hours yesterday getting the tech support folks to go
<br>in an manually CHOWN (change owner) on the affected files, just so my backup<br>scripts could function properly at midnight.<br><br>Victor suggests that you "try chmod 777" on the files, but that will not<br>
work. You can not CHMOD a file that you don't have permission to CHMOD,<br>because you're not the owner.<br><br>If you want to verify the problem, in your FTP program or whatever, look at<br>the far right of the directory listings containing those files. You may
<br>normally see your own user name, in the last two columns -- this is the<br>Owner and Group (UID, GID).<br><br>In the erroring case, you will see that is 'apache' or 'root' or something<br>that is _not_ you. You're stuck.
<br><br><br>These image modules really do make a commitment to Drupal/CS problematic.<br><br>It's such a common web task to insert an icon or other image into a post,<br>yet it's practically impossible.<br>--<br>Gary<br>
<br>
--<br>[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.drupal.org/</a> ]<br></blockquote></div><br><br clear="all"><br></span>
</div><div style="direction: ltr;"><span class="sg">-- <br>
<a href="http://www.victortrac.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.victortrac.com</a>
</span></div></blockquote></div><br><br clear="all"><br>-- <br><a href="http://www.victortrac.com">http://www.victortrac.com</a>