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.
<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>-- <br>
<a href="http://www.victortrac.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.victortrac.com</a>