Hi all,
I've just added filemanager and acidfree to my site.
I encounter a problem when trying to upload a picture. I get repeatedly the following error messages:
warning: fopen(private/filemanager.lck): failed to open stream: Permission denied in /home/simon/public_html/modules/filemanager.module on line 654.
warning: flock(): supplied argument is not a valid stream resource in /home/simon/public_html/modules/filemanager.module on line 655.
warning: is_dir(): Stat failed for private/working (errno=13 - Permission denied) in /home/simon/public_html/includes/file.inc on line 533.
I assume it's a problem of setting the right permission. So to which files do I have to change permissions?
Thanks for help.
Simon
A shot in the dark - I've never messed with the acidfree module, but I'm guessing Apache (it is apache, right? :)) isn't running as your user, and ./private/filemanager.lck file isn't globally writable. Try chmod 777 ./private/filemanager.lck.
On 4/2/06, Simon Schneebeli simon.schneebeli@okko.org wrote:
Hi all,
I've just added filemanager and acidfree to my site.
I encounter a problem when trying to upload a picture. I get repeatedly the following error messages:
warning: fopen(private/filemanager.lck): failed to open stream: Permission denied in /home/simon/public_html/modules/filemanager.module on line 654.
warning: flock(): supplied argument is not a valid stream resource in /home/simon/public_html/modules/filemanager.module on line 655.
warning: is_dir(): Stat failed for private/working (errno=13 - Permission denied) in /home/simon/public_html/includes/file.inc on line 533.
I assume it's a problem of setting the right permission. So to which files do I have to change permissions?
Thanks for help.
Simon
[ Drupal support list | http://lists.drupal.org/ ]
On 4/2/06, Simon Schneebeli simon.schneebeli@okko.org wrote:
Hi all,
I've just added filemanager and acidfree to my site.
I encounter a problem when trying to upload a picture. I get repeatedly the following error messages:
warning: fopen(private/filemanager.lck): failed to open stream: Permission denied in /home/simon/public_html/modules/filemanager.module on line 654.
warning: flock(): supplied argument is not a valid stream resource in /home/simon/public_html/modules/filemanager.module on line 655.
warning: is_dir(): Stat failed for private/working (errno=13 - Permission denied) in /home/simon/public_html/includes/file.inc on line 533.
I assume it's a problem of setting the right permission. So to which files do I have to change permissions?
Thanks for help.
Simon
"Victor Trac" wrote:
A shot in the dark - I've never messed with the acidfree module, but I'm guessing Apache (it is apache, right? :)) isn't running as your user, and ./private/filemanager.lck file isn't globally writable. Try chmod 777 ./private/filemanager.lck.
Simon, I've been having the same exact problems with 'attachment' + 'filemanager' modules.
Drupal just has a very long way to go before it could really be considered "friendly" for virtual hosting.
In your case, as in mine, the script(s) are designed to CHMOD the permissions on some files so that they are owned by 'apache' in the group 'apache'. (This means UID 'apache' and GID 'apache'.)
The problems caused by this are, as you've seen, problems in even running the modules at all, but the problems get worse.
If you have any automated server/db backup scripts, they will fail also if they don't have the correct permissions -- which they won't, in this case.
I would suggest that you (like me) find some other image uploading tool to use in conjunction with Drupal, and just stick with that.
I can not figure how a software like this has gone for so long without any adequate image uploading capability.
Everyone seems to think "image galleries" rather than just "insert a flipping image into this content".
Anyway, using images in Drupal/CS content is real PITA and these permissions errors are as well.
I had to spend several hours yesterday getting the tech support folks to go in an manually CHOWN (change owner) on the affected files, just so my backup scripts could function properly at midnight.
Victor suggests that you "try chmod 777" on the files, but that will not work. You can not CHMOD a file that you don't have permission to CHMOD, because you're not the owner.
If you want to verify the problem, in your FTP program or whatever, look at the far right of the directory listings containing those files. You may normally see your own user name, in the last two columns -- this is the Owner and Group (UID, GID).
In the erroring case, you will see that is 'apache' or 'root' or something that is _not_ you. You're stuck.
These image modules really do make a commitment to Drupal/CS problematic.
It's such a common web task to insert an icon or other image into a post, yet it's practically impossible. -- Gary
Hello all,
Thanks for your help.
I managed to fix my problem (although it took me really a lot of time). What I did: - change the permissions of "files" folder to 777 - put the "private" folder inside the "files" folder
That magically did the trick (I have too little knowledge of programming to know why, but it works).
But you're right, that the handling of pictures could be improved in Drupal. Actually I switched from Joomla to Mambo just recently because I was not so convinced from Joomla. Drupal seamed to have a cleaner interface and as I read was better programmed. By now, I'm still not able to say which one of the two is better. The fact that the documentation is spread so far is another problem. Anyway, I'm glad that such programmes and documentation is made available for free.
Simon
Lists wrote:
On 4/2/06, Simon Schneebeli simon.schneebeli@okko.org wrote:
Hi all,
I've just added filemanager and acidfree to my site.
I encounter a problem when trying to upload a picture. I get repeatedly the following error messages:
warning: fopen(private/filemanager.lck): failed to open stream: Permission denied in /home/simon/public_html/modules/filemanager.module on line 654.
warning: flock(): supplied argument is not a valid stream resource in /home/simon/public_html/modules/filemanager.module on line 655.
warning: is_dir(): Stat failed for private/working (errno=13 - Permission denied) in /home/simon/public_html/includes/file.inc on line 533.
I assume it's a problem of setting the right permission. So to which files do I have to change permissions?
Thanks for help.
Simon
"Victor Trac" wrote:
A shot in the dark - I've never messed with the acidfree module, but I'm guessing Apache (it is apache, right? :)) isn't running as your user, and ./private/filemanager.lck file isn't globally writable. Try chmod 777 ./private/filemanager.lck.
Simon, I've been having the same exact problems with 'attachment' + 'filemanager' modules.
Drupal just has a very long way to go before it could really be considered "friendly" for virtual hosting.
In your case, as in mine, the script(s) are designed to CHMOD the permissions on some files so that they are owned by 'apache' in the group 'apache'. (This means UID 'apache' and GID 'apache'.)
The problems caused by this are, as you've seen, problems in even running the modules at all, but the problems get worse.
If you have any automated server/db backup scripts, they will fail also if they don't have the correct permissions -- which they won't, in this case.
I would suggest that you (like me) find some other image uploading tool to use in conjunction with Drupal, and just stick with that.
I can not figure how a software like this has gone for so long without any adequate image uploading capability.
Everyone seems to think "image galleries" rather than just "insert a flipping image into this content".
Anyway, using images in Drupal/CS content is real PITA and these permissions errors are as well.
I had to spend several hours yesterday getting the tech support folks to go in an manually CHOWN (change owner) on the affected files, just so my backup scripts could function properly at midnight.
Victor suggests that you "try chmod 777" on the files, but that will not work. You can not CHMOD a file that you don't have permission to CHMOD, because you're not the owner.
If you want to verify the problem, in your FTP program or whatever, look at the far right of the directory listings containing those files. You may normally see your own user name, in the last two columns -- this is the Owner and Group (UID, GID).
In the erroring case, you will see that is 'apache' or 'root' or something that is _not_ you. You're stuck.
These image modules really do make a commitment to Drupal/CS problematic.
It's such a common web task to insert an icon or other image into a post, yet it's practically impossible. -- Gary
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.
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.
"Victor Trac" wrote:
A shot in the dark - I've never messed with the acidfree module, but I'm guessing Apache (it
is
apache, right? :)) isn't running as your user, and
./private/filemanager.lck
file isn't globally writable. Try chmod 777 ./private/filemanager.lck.
Simon, I've been having the same exact problems with 'attachment' + 'filemanager' modules.
Drupal just has a very long way to go before it could really be considered "friendly" for virtual hosting.
In your case, as in mine, the script(s) are designed to CHMOD the permissions on some files so that they are owned by 'apache' in the group 'apache'. (This means UID 'apache' and GID 'apache'.)
The problems caused by this are, as you've seen, problems in even running the modules at all, but the problems get worse.
If you have any automated server/db backup scripts, they will fail also if they don't have the correct permissions -- which they won't, in this case.
I would suggest that you (like me) find some other image uploading tool to
use in conjunction with Drupal, and just stick with that.
I can not figure how a software like this has gone for so long without any adequate image uploading capability.
Everyone seems to think "image galleries" rather than just "insert a flipping image into this content".
Anyway, using images in Drupal/CS content is real PITA and these permissions errors are as well.
I had to spend several hours yesterday getting the tech support folks to go in an manually CHOWN (change owner) on the affected files, just so my backup scripts could function properly at midnight.
Victor suggests that you "try chmod 777" on the files, but that will not work. You can not CHMOD a file that you don't have permission to CHMOD, because you're not the owner.
If you want to verify the problem, in your FTP program or whatever, look at the far right of the directory listings containing those files. You may normally see your own user name, in the last two columns -- this is the Owner and Group (UID, GID).
In the erroring case, you will see that is 'apache' or 'root' or something that is _not_ you. You're stuck.
These image modules really do make a commitment to Drupal/CS problematic.
It's such a common web task to insert an icon or other image into a post, yet it's practically impossible. -- Gary
-- [ Drupal support list | http://lists.drupal.org/ ]
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:
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 (http://www.suphp.org/Home.html).
This problem is pretty common across many different php packages that allow users to upload files, not just Drupal.
-Victor
On 4/6/06, Victor Trac victor.trac@gmail.com wrote:
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.
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.
"Victor Trac" wrote:
A shot in the dark - I've never messed with the acidfree module, but I'm guessing Apache
(it is
apache, right? :)) isn't running as your user, and
./private/filemanager.lck
file isn't globally writable. Try chmod 777
./private/filemanager.lck.
Simon, I've been having the same exact problems with 'attachment' + 'filemanager' modules.
Drupal just has a very long way to go before it could really be considered "friendly" for virtual hosting.
In your case, as in mine, the script(s) are designed to CHMOD the permissions on some files so that they are owned by 'apache' in the group 'apache'. (This means UID 'apache' and GID 'apache'.)
The problems caused by this are, as you've seen, problems in even running the modules at all, but the problems get worse.
If you have any automated server/db backup scripts, they will fail also if they don't have the correct permissions -- which they won't, in this case.
I would suggest that you (like me) find some other image uploading tool to use in conjunction with Drupal, and just stick with that.
I can not figure how a software like this has gone for so long without any adequate image uploading capability.
Everyone seems to think "image galleries" rather than just "insert a flipping image into this content".
Anyway, using images in Drupal/CS content is real PITA and these permissions errors are as well.
I had to spend several hours yesterday getting the tech support folks to go in an manually CHOWN (change owner) on the affected files, just so my backup scripts could function properly at midnight.
Victor suggests that you "try chmod 777" on the files, but that will not work. You can not CHMOD a file that you don't have permission to CHMOD, because you're not the owner.
If you want to verify the problem, in your FTP program or whatever, look at the far right of the directory listings containing those files. You may
normally see your own user name, in the last two columns -- this is the Owner and Group (UID, GID).
In the erroring case, you will see that is 'apache' or 'root' or something that is _not_ you. You're stuck.
These image modules really do make a commitment to Drupal/CS problematic.
It's such a common web task to insert an icon or other image into a post, yet it's practically impossible. -- Gary
-- [ Drupal support list | http://lists.drupal.org/ ]
-
Lists -
Simon Schneebeli -
Victor Trac