Cron errors after Upgrade to Drupal 6.9: "File(/tmp/mysql.sock) is not within the allowed path"

Exactly the same error here in my logs. Did you perhaps find a solution? Thanx!

Even I am getting the same error and looking for a solution.

Disabling PoorMansCron has no effect. Started receiving error message in log on 1.18.09 for no apparent reason. Anyone looking at this?

Did someone find a solution?

http://drupal.org/search/apachesolr_search/open_basedir%20restriction%20....

using parts of the error message and drupal.org search will provide clues. I've upgraded quite a few sites to 6.9 and don't see this problem.

If you are reporting a bug, it needs to consist of three things:

* What are the steps required to reproduce the bug?
* What behavior were you expecting?
* What happened instead?

Please include as much information as you can: OS, webserver name and version, PHP version, Drupal version, Drupal path, and everything else you might feel is relevant. There is no such thing as a bug report that is too detailed.

When filing a bug report, the above is asked of you on each issue you create. Not providing enough information for others to test is problematic and likely to result in being bypassed in issue queues.

Yes the first three questions were answered but the OS information is important.

I don't believe it to be a code issue. I believe it to be a server issue.

Is safe mode enabled in php?

seems odd that such an old version of apache is being used with such a new version of php.

If 6.9 is installed on the same server in a testing folder, without it being upgraded are the same issues present? If so, it has nothing to do with the upgrade and likely a change in the server environment. To verify reinstall 6.7 in same testing folder. Are problems removed ? if so, then we can compare the changes made between 6.7 and 6.9 for a culprit.

it would certainly help narrow down where to look for a problem yes. This is not a wide spread issue or there would be reports of it all over the place. Most of the reports I read were related in some way to safe mode or incorrect placement of themes in /themes/ rather than in sites/all/themes and none of those reports had anything to do with cron.php.

The other thing of note here, is that when using google to search the error there are quite a few sites that have been indexed with the error message. That said, of the dozen I looked at, none of them were drupal sites.

Question

When viewing dynamic pages, I see the following error: Warning: main(): open_basedir restriction in effect. File(/full/path/to/cgi-bin/movabletype/php/mt.php) is not within the allowed path(s): (/full/path/to/tmp) in /full/path/to/blog/mtview.php on line 2
Answer

This error indicates that your host has enabled the PHP open_base_dir setting on your server. Your host needs to add your Movable Type installation folder to the allowed paths for this setting (i.e., add the file path referenced in the error as "not within the allowed path").

The open_base_dir setting is primarily used to prevent php scripts for a particular user from accessing files in another user's account. So usually, any files in your own account should be readable by your own scripts.

replace movabletype with drupal in the Q&A. Thus I'd be asking my host if they recently made the change mentioned.

more information:

open_basedir string

Limit the files that can be opened by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off.

When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink.

The special value . indicates that the working directory of the script will be used as the base-directory. This is, however, a little dangerous as the working directory of the script can easily be changed with chdir().

In httpd.conf, open_basedir can be turned off (e.g. for some virtual hosts) the same way as any other configuration directive with "php_admin_value open_basedir none".

Under Windows, separate the directories with a semicolon. On all other systems, separate the directories with a colon. As an Apache module, open_basedir paths from parent directories are now automatically inherited.

The restriction specified with open_basedir is actually a prefix, not a directory name. This means that "open_basedir = /dir/incl" also allows access to "/dir/include" and "/dir/incls" if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: "open_basedir = /dir/incl/"

Note: Support for multiple directories was added in 3.0.7.

The default is to allow all files to be opened.

httpd.conf is not available to you on a shared server. Thus your host would have to look into this and whether or not it can be turned back off.

if tmp is defined as an allowed path in httpd.conf then I've run my course with helping here and will hope someone else steps in with an answer or something else for you to look into. My research has run dry.

good luck.

I have the same problem, but on a Drupal 6.10 site, not a Drupal 6.9.

I think I can very definitely say it is a server configuration problem because, as it happens, I moved my site to a new host and upgraded to Drupal 6.10 at the same time.

The error did not occur on the old host with Drupal 6.9, and I don't see it any time on the new host except when the cron is run.

Also, I am not running in safe mode, and open_basedir is set to /home:/tmp:/usr

My exact error is:
is_dir() [<a href='function.is-dir'>function.is-dir</a>]: open_basedir restriction in effect. File(/tmp/mysql.sock) is not within the allowed path(s): (/home:/tmp:/usr) in /home/wickwood/public_html/includes/file.inc on line 891.

I have submitted a ticket to my hosting admin, and will report back anything that I discover.

Steve

Sounds very much like a configuration issue. Moving to a support request.

Just taking a stab at this: could it be caused by the file mysql.sock actually being a symlink to a part of the filesystem that is outside the open_basedir?

I don't know if PHP's error/warning would show the resolved symlink (real path) or just the symlink.

Maybe you could ask your provider if that is the case?

@wickwood: Could you also post some more info on your setup and especially OS and PHP version ?

- Arie

I stopped watching this thread after upgrading to 6.10 because the error message went away.

Today I upgraded two modules fckeditor 6.x-1.3 and pathauto 6.x-2.x-dev (2009-Mar-21) and the message is back:

warning: is_dir() [function.is-dir]: open_basedir restriction in effect. File(/tmp/mysql.sock) is not within the allowed path(s): (/home/manogolf/:/usr/lib/php:/usr/local/lib/php:/tmp) in /home/manogolf/public_html/sirarea22/includes/file.inc on line 891.

I wouldn't know if there is a relationship or if it is a coincidence.

A ticket to my hosting cured the problem. Thanks for pointing out.

rene_w,

I apologize for not spotting your question sooner.

My host enabled php open base directory.
Hope that means something to you because it doesn't to me.
I am just pleased they could help and it is no longer an issue.

After upgrading I also got "File(/tmp/mysql.sock) is not within the allowed path(s)" and seeing so many messages with no solution tells me this must be a bug. Has anyone submitted this as a bug? If so, any updates?

Thanks,

TC

because it was a configuration issue I'm marking won't fix.

After searching a while, found one solution:
In some cases the temporary directory in File System settings (/admin/settings/file-system)
is set to '/tmp'. After changing it to 'sites/default/temp' the problem was corrected.