zigger wrote:

*** Bug 1407 has been marked as a duplicate of this bug. ***

Jan wrote:

This may be a permissions problem. Check them carefully, all the way to root, through the hard directory structure.

I got the same error, and carefully checked permissions all the way to root and they were all good. But this was a
symlinked path! The symlink permissions that allowed read access to user www (the user running httpd) ran up to the
web server root directory, and were okay, but the *hard link* path was in a user directory, which had perms of
"drwxrwx--x", which did not allow user "www" read access. Changing this to "drwxr-xr-x" solved the install problem.
This was a couple levels above the actual website directory.

This is doubly odd, since the website in the user directory had been working fine. Obviously, Apache could get in
through the symlink, but MediaWiki must be resolving and attempting to use the hard link path. So I consider this a
work-around, rather than a bugfix -- MediaWiki *should* install in any directory that Apache has no problem with.
This makes me think there may be problems installing in a chroot jail.

This was on MacOS X. Here are the actual paths (name changed to protect the guilty :-)

Hardlink path: /Users/xxx/Sites/yyy/ -- directory "xxx" (user name) had perms "drwxrwx--x"

Symlink path: /Library/WebServer/yyy/ -- directory "yyy" is a symbolic link to directory "yyy" above

Hope this is helpful. Contact me if you need more info.

Jan wrote:

Jamie Bliss has isolated this to the variable $IP in LocalSettings.php. The install script /wiki/config/index.php is
apparently using getcwd() to write this setting out, which will be a hard linked path to root.

Suggested fix: put the discovered path in the install form and allow the user to change it to a symlinked path if they
have need to restrict permissions on the hard linked path.

This behavior may affect other situations, like remote mounted filesystems or chroot(8) jails.

This should be fixed now in 1.4.1.

The problem is that when a parent directory is not readable, realpath() cannot resolve the
relative path to a canonical path. PHP then puts the relative form into its list of already-included
files, and a different form will not be recognized as the same file (../includes/Namespace.php vs
includes/Namespace.php).

I've now got it setting up the include path first and using more consistent relative paths, which
gets it through the installer on my Mac when I set my home directory to o-r.

[adjusting bug to fix db consistency warning; operating system was set to a no longer
existing value]