Got exception:
Fatal error: require_once(): Failed opening required '/usr/share/nginx/www//usr/share/nginx/shared/files/mailsystem/' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/nginx/www/includes/ on line 3046 Call Stack: 0.0005 337816 1. {main}() /usr/share/nginx/www/index.php:0 0.0575 874476 2. drupal_bootstrap() /usr/share/nginx/www/index.php:20 0.3157 5913664 3. _drupal_bootstrap_full() /usr/share/nginx/www/includes/ 1.6022 34632696 4. module_invoke_all() /usr/share/nginx/www/includes/ 1.6865 35623620 5. call_user_func_array() /usr/share/nginx/www/includes/ 1.6865 35623812 6. mailsystem_init() /usr/share/nginx/www/includes/ 1.6865 35623812 7. mailsystem_get_classes() /usr/share/nginx/www/sites/all/modules/mailsystem/mailsystem.module:17 1.7163 35995128 8. class_exists() /usr/share/nginx/www/sites/all/modules/mailsystem/mailsystem.module:306 1.7163 35995448 9. drupal_autoload_class() /usr/share/nginx/www/includes/ 1.7163 35995524 10. _registry_check_code() /usr/share/nginx/www/includes/

It's pretty bad, I though uninstalling and reinstalling would help, but in troubleshooting I deleted the mailsystem directory in my files directory and now get WSOD. Any idea how this screwed up path got created?


husumiao’s picture

This is the MAIL inc file path issue. Just try to do these 2 steps:
1. Special the file path on mailsysytem.module.
// Build the class filename.
$class_file = drupal_realpath($class_dir) . DIRECTORY_SEPARATOR . "$";

Change it like to:
$class_file = str_replace('public:/', variable_get('file_public_path'), $class_dir) . DIRECTORY_SEPARATOR . "$";
Just example, you just need change the realpath for the inc file.

2. Clear older data for the mail inc file recorder.

db_query("DELETE FROM {registry}");
db_query("DELETE FROM {registry_file}");

I'm worded on mailsystem-7.x-2.28 and htmlmail-7.x-2.60.
Detail solution guide in here:

pillarsdotnet’s picture


technicalknockout’s picture

Tried following the steps from #1 - but got the same error. This happens after submitting the mailsystem settings form with create a new class options HTMLMailSystem format() and SmtpMailSystem mail() methods selected.

Step 2 did help restore the site. BTW another way to restore the site is with a symlink in the drupal root directory pointing to the highest parent directory of drupal (in my case '/usr' which appears in the error message after the double directory-separator characters // )

esclapes’s picture

Version:7.x-2.34» 7.x-2.x-dev
Status:Active» Needs review
new1.6 KB

This happens, at least in our case, whenever files is a symlink to another location.

This patch uses variable_get to build the file path. It tries to use the private filesystem first, as it seems a better place for code. Not sure if that is a good choice and I haven't tried the patch within a installation with private files enabled, though.

tobiasb’s picture

new1.58 KB

* fixed the indentation (tab)

tripper54’s picture

new1.67 KB

Patch in #5 caused fatal errors : 'Only variables can be passed by reference' in the file_prepare_directory function calls.

updated patch attached.

ptmkenny’s picture

Status:Needs review» Needs work

I was unable to apply the patches in #6 or #5. I am on Mac OS X using MAMP.

I tried applying the patch like this:
patch -p1 ../../../patches/mailsystem.1534706.6.patch

but it simply hung and I had to cancel it manually.

I then just opened up the patch and made the changes manually in Vim. However, when I did this and attempted to create a new class with the module (on the mail system settings page, create a new class with format() MimeMail and mail() defaultMail), I got the following error:
The specified file temporary://filef5qHuB could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

In the system log, the following other entries are present:
Message Notice: Undefined variable: class_file in mailsystem_create_class() (line 151 of /srv/bindings/ca3676e8f9774d40abd26af71993903a/code/sites/all/modules/contrib/mailsystem/mailsystem.module).
Message Notice: Undefined variable: drupal_root in mailsystem_create_class() (line 151 of /srv/bindings/ca3676e8f9774d40abd26af71993903a/code/sites/all/modules/contrib/mailsystem/mailsystem.module).

I don't know how to debug this further but I'd like to report that it didn't work for me.

I'm using the latest 2.x-dev version (2012-Apr-11) of mailsystem as well as Drupal 7.18.

ptmkenny’s picture

I was able to get it working using a custom module and the solution described here:

nickgs’s picture

new605 bytes

I have a site running on Acquia's dev cloud and hit this problem. Being that the files directory is symlinked I believe this is causing the require_once to fail. This basically took down the entire site and required a restore.

Using the technique described in #8 worked for me on the dev cloud. I've attached the small module I created to make this happen as an example.

Hope this helps.



esclapes’s picture

Status:Needs work» Needs review

Hi there,

Pach in #6 applies cleanly to both dev and 7.x-2.34 releases. The command to apply the patch is:

patch -p1 < path/to/patch/mailsystem.1534706.6.patch

It should be invoked from mailsystem directory (usually sites/all/modules/contrib/mailsystem)

It looks fine to me but I have no easy way to test it right now.

Sorry for my patch in #4. After fixing our problem, I kind of rewrote the solution and posted it without actually testing it. My bad. However, I can say the idea behind it works just fine. We are using it right now.

On the other hand, I would say a solution to #1369736: Alternative locations for "created" Class files? would be probably better than using the filesystem. I don't think this two issues should be considered duplicate, but they address the same problem.

mto’s picture

I've also ran into this problem - thankfully after several hours of tweaking and searching found this thread!
The patch in #6 works for me too with 7.x-2.34.

Tested on a dev and staging site with Acquia Cloud and seems to work perfectly. Thanks!

technicalknockout’s picture

Not sure if this would help issues like this, but figured might as well pose the question: how feasible would it be to have classes/files generated by this module be managed by the features module and exported to module code?

thelocaltourist’s picture

Issue summary:View changes

#6 worked for me as well. Can this be committed? I spent hours trying to fix this issue.

JeroenT’s picture

Status:Needs review» Reviewed & tested by the community

#6 Worked for me.

jygastaud’s picture

#6 works for me too.
I had that kind of issue when with phpmailer module/class when combined with memcache.

dxx’s picture

Ok for #6.
I use memcache and a relative path for my private folder (like "../prvt/").
I have solved with this patch and edited manually the registry table in db.

iwhitcomb’s picture

This is a cool little feature of this module, but I have to ask; is this really the most reliable way of handling this?! Typically the files directory doesn't/shouldn't get version controlled thus the file(s) generated by this module doesn't get transported with the rest of the code base like it needs to. If you're using something like stage_file_proxy like I am, or the file gets deleted for any reason then you're in trouble.

I strongly second #12 -- these generated files belong in a module/feature somewhere, not in the files folder.

samuel.mortenson’s picture


DrSage’s picture

To fix this issue we could update update path to new library by updating path in the registry table.
update registry set filename = 'sites/default/files/mailsystem/' where name='MimeMailSystem__DefaultMailSystem'

And another solution is to use

rakesh.gectcr’s picture

for me

db_query("DELETE FROM {registry}");
db_query("DELETE FROM {registry_file}");


  • Nafes committed 28f10e1 on 7.x-2.x authored by tripper54
    Issue #1534706 by esclapes, tobiasb, tripper54: Wrong directory...
Nafes’s picture

Committed. Thanks!

Nafes’s picture

Status:Reviewed & tested by the community» Fixed

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.