Upload paths?? "The webserver does not have permissions to read that directory. "

Gallery version: gallery-2.0
PHP version: Php 4.3.11
PHPInfo Link: PhpInfo found Here
Webserver: Apache2 for win32
Database: MySql 4.0.25
Activated toolkits: Image Magik, GD
Operating system :Windows Xp Pro
Browser: Maxthon 1.3.3 build 50 (An IE Shell Browser)

No Matter which path I put in I can't seem to make the file upload path work I keep recieving this error. I have no .htaccess files inside that directory, I double checked just in case.

[img]http://MetalHell.ServeMp3.Com/g2/g2_error.gif[/img]

I did a search and found only 2 posts about this neither which appeared to have been followed up on with the correct information on how to fix it. How can I fix this error?

T.Y.I.A.
Angel

I'm fighting a similar issue on an OpenBSD box.

Gallery version = 2.0-rc-2 core 0.9.36
PHP version = 4.3.10 apache
Webserver = Apache/1.3.29 (Unix) PHP/4.3.10 mod_ssl/2.8.16 OpenSSL/0.9.7d
Database = mysql 4.0.23
Toolkits = ArchiveUpload, Exif, NetPBM
Operating system = OpenBSD 3.7 GENERIC#50 i386
Browser = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; SV1)

A link to my phpinfo:
http://www.lowtek.ca/gallery/phpinfo.php

I'm trying to set under the Admin Options / General section -> Local Server Upload Paths. When I type in /tmp I get the error message: "The webserver does not have permissions to read that directory." which is clearly not true.

drwxrwxrwt 2 root wheel 512 Sep 22 07:01 tmp

I realize I'm back a level on Gallery, but having looked at the php code, this has to be something stupid with my setup. I tried (and failed) to add some extra debug to the php script. If someone has hints on this I'll take another run.

In my situation I cannot even add /tmp to the upload path and the permissions on /tmp are fine
drwxrwxrwt 2 root wheel 512 Sep 22 07:01 tmp

The weird thing is that everything else seems to be working fine, I can even use the Import from Gallery1 and point it at a "random" path on my system that contains old Gallery data.

What will help me
1) someone pointing out the obvious I've overlooked
2) tips on how to add debug statements to the php code in modules/core/SimpleCallback.inc so I can figure out why the system thinks it can't read the /tmp directory

Thanks
Roo

Updated my original message with phpinfo link and some more details.

If you examine the information I posted more carefully, you'll see that I am using OpenBSD 3.7 - not SELinux.

I wrote a very simple php program

<?php
$filename = '/tmp';
if (is_readable($filename)) {
echo 'The file is readable';
} else {
echo 'The file is not readable';
}
?>

And tested it. The result was "The file is readable", as I would expect. So, clearly php can see /tmp -- but for some reason, I still have this issue.

Any other ideas? (and thanks for ultra-speedy responses)
Roo

I believe SELinux tooling and OpenBSD don't mix at all. However, OpenBSD does have some quirky security things, so you're guess may not be entirely off the mark. Let's put this aside and dig into the code.

I modified modules/core/AdminCore.inc to have:

  } else if (!$platform->is_readable($realPath)) {
   $error[] = 'form[error][uploadLocalServer][newDir][notReadable]';
   var_dump($realPath); exit;
  }

And this is the output I got: bool(false)

Which seems odd, so I moved the hack further up in the code to line 122 or so:

var_dump($path); exit;
  $realPath = GalleryCoreApi::convertFromUtf8($path);

And I get: string(4) "/tmp"

This is more sensible. A double check that the $realPath is bogus..

  $realPath = GalleryCoreApi::convertFromUtf8($path);
var_dump($realPath); exit;

Results in:bool(false) -- confirming that I'm not on crack.

So clearly I need to dig into the convertFromUtf8() function. The var_dump();exit(); trick is super handy for tracking this down, thanks for the php debug tip. I'll dig around a bit more and see if I can solve this myself.

Roo

My hope is that at one point along the way, the real problem will be uncovered and a simple solution will be available to everyone.

Your note does indicate some confusion about this feature. The upload directory is used to configure one of the ways that you can bring in data to Gallery. Any users who can create/modify albums are going to be able to upload stuff (be it via a web browser or other means).

This upload directory is to allow users who have the ability to place files on the webserver's disk to point at an archive (or tree) of pictures and suck them in to gallery. I suspect if you have users who can't modify albums, but who can put files on your server -- you've got bigger problems

If you're using XP, many people are falling into the trap of using the wrong type of paths it seems. I fully agree that the error message needs to be a bit more descriptive. If you really need help, you need to post the information asked for in the FAQ http://codex.gallery2.org/index.php/Gallery2:FAQ#What_information_is_required_when_I_ask_for_help_in_the_forums.3F

Ok, without further delay -- onto some more confusing goop.

I've done more digging into my problem. I believe I'm getting closer.

line 158 in modules/core/classes/helpers/GalleryCharsetHelper_simple.class

    function convertFromUtf8($string, $targetEncoding=null) {
        global $gallery;
        $phpVm = $gallery->getPhpVm();

        if (empty($targetEncoding)) {
            $targetEncoding = GalleryCharsetHelper_simple::detectSystemCharset();
var_dump($targetEncoding);var_dump($string);exit();
        }

Is giving me output that looks like: "%a %b %d %H:%M:%S %Y" string(4) "/tmp"

Now, this looks a lot like the date time format string that was processed previously, I'm unclear why it is what I'm getting back from detectSystemCharset();

I also know that in my situation, the path I'm taking is to recode the string.

        } else if ($phpVm->function_exists('recode_string')) {
            return $phpVm->recode_string('UTF-8..' . $targetEncoding, $string);

I suspect trying to recode the string as 'UTF-8..%a %b %d %H:%M:%S %Y' isn't terribly meaningful.

Thanks very much valiant this fixed things with no problem.

MetalHellsAngel: cool

Andrew_Low: good research Could you please file a g2 bug on http://sf.net/projects/gallery/ , a bug title like "[G2] nl_langinfo(CODESET) returns date format on OpenBSD" seems appropriate.
your detection for a broken nl_langinfo(CODESET) seems to be ok. So chances are good this will be soon in G2. we'll have to check if this might be a problem for other OS and write a small unit test, that's it. thanks

akatheone: Andrew_Low already explained it. i guess it would make sense to add another G2 permission for the "add from local server" method. not every user that is allowed to add items should be allowed to add files from the local server upload path. maybe, we even need a permission per path.
right now, you should make sure you delete everything in your local upload path once you're finished adding, if you have other users in g2 with add item permission.

My problem was very specific to OpenBSD as it turns out.

If you want to see if your having the same problem (peter_k I doubt you were as you resolved it another way). Run this php script:

<?php
echo nl_langinfo (CODESET);
echo nl_langinfo (D_T_FMT);
?>

If you get output that looks something like:
%a %b %d %H:%M:%S %Y%a %b %d %H:%M:%S %Y
(ie: the date/time format string twice in a row) then you're probably running OpenBSD or another OS with exactly the same problem.

I would suggest that the FAQ might be improved to cover this topic. It seems that a lot of WindowsXP users are hitting the "you need to use the drive letter in your full path" problem.

Peter_k hit a variant of this problem with the webserver having visibility into a subtree root (not sure the right words to explain this).. or so it seems to me. Again, possibly a FAQ item.

I'd agree a permission setting on local upload is a good idea. Another suggestion would be just add the path, do your upload, and remove the path - if there are no paths - local upload is disabled. That way only admins can do a local upload.

I personally see the local upload as a good way to bulk upload and get things started. You probably won't do this frequently.

Valiant: I'll log a bug later today, thanks for the help (and the pat on the back) - I'm just happy that I can upload from local dirs now [tested it, it works fine with my hack]

Roo

I've created a bug https://sourceforge.net/tracker/index.php?func=detail&aid=1301421&group_id=7130&atid=107130 to track the OpenBSD problem with Gallery2.

Roo

G2 now should now catch this case on OpenBSD.. fix in CVS now, will also be in 2.1-RC-2.

what do you get for <?php var_dump(nl_langinfo(CODESET)); ?>

Help
I am very new to working on a website. Please can help me with questions below

1)How can i link my website to gallery

2) on set up page on gallery, they are asking, i donot understand let a lone answer.

Can any one help

Thanks Guys & Girls

all the best Doug