Bug in /usr/local/dir*/scripts/webmail.sh

pucky

Verified User
Joined
Sep 9, 2006
Messages
758
For those of you getting weird errors in your logs from /var/www/html/webmail/tmp where the error is related to CANNOT LSTAT you will be relieved to know there is a very simple fix for it.

The script /webmail.sh has a bug in it so when your webmail is installed on a new server the tmp permission is wrong.

The script does a chmod 700 on /var/www/html/webmail/tmp. Thats wrong, it should be chmod 755 /var/www/html/webmail/tmp.

If you are getting CANNOT LSTAT /var/www/html/webmail/tmp ijn your logs go type;

chmod 755 /var/www/html/webmail/tmp and your errors will go away.

webmail.sh should be;

Code:
$TAR xzf ${FILE} -C ${DEST}
$MKDIR -p $TMPDIR
[B]$CHMOD -f -R 755 $TMPDIR;[/B]
$CHOWN -f -R apache:apache $TMPDIR;

not

Code:
$TAR xzf ${FILE} -C ${DEST}
$MKDIR -p $TMPDIR
$CHMOD -f -R 700 $TMPDIR;
$CHOWN -f -R apache:apache $TMPDIR;

Maybe the DA crew should fix this issue as it occurs on all new installations and leads to annoying errors in the logs. The question about why this occures has been asked in the forums OVER AND OVER and nobody from DA has bothered to offer a fix, at least i havent found a post releated to fix. Its simply been ignored. :rolleyes:
 
Last edited:
700 should work fine for webmail, unless you are running something like suphp where php is running as the user. Normally webmail is running as user apache and the chown at the end of webmail.sh does the chown apache, so that user should have read,write,execute perms on that directory.
 
Nope, the logs are full of erros with a 700. Try chowning your /tmp directory to 700 and see what happens.
 
Wow, finally a solution for this problem. A tread with this issue exists for 5 months now. Great work pucky!

Edit:
Tought this was the sollution but problem still exists.
 
Last edited:
Hello,

Thanks for the info.. I'm hesitant do make it world readable.
Does 711 work on /var/www/html/webmail/tmp? that would be safer than 755.

Let me know and I'll update the scripts

Thanks,
John
 
Make sure the owner of /var/www/html/webmail/tmp (also whole webmail) is apache not root then permission 700 should be work fine for webmail.

I'm surprise what da doing with webmail/tmp folder?
It's just a webmail da have no business to do with it, am I right or I miss something?
 
Last edited:
Hello,

We should leave /tmp out of it ;) .. it's not related to webmail.
/var/www/html/webmail/tmp is the one being used.

I'm also a bit confused as to why 755 would be required, unless he's running su_php.

*ARE* you running suphp? 700 should be enough to work for the apache user if it's owned by apache.

John
 
DirectAdmin Support said:
Hello,

We should leave /tmp out of it ;) .. it's not related to webmail.
/var/www/html/webmail/tmp is the one being used.

John

Sorry, I mean /var/www/html/webmail/tmp (edited) :eek:

Also my server using suphp, anyway it's will run as script owner "apache" as we set to webmail/*.php
 
Last edited:
Hold on a second... what error log are you taking the lstat error from? If it's the apache log, ok. But, if it's the directadmin error.log, then that has nothing to do with apache or the chmod. It means that the path that DA is checking for disk usage doesn't exist. Chmodding won't change the existance of a file (checking is done as root, so chmod does nothing). I checked over the code and a "quiet check" was added to it, so it doesn't complain into the log. If you see the error, update your version of DirectAdmin. (that quiet check was added a long time ago)

So, if it's in your directadmin/error.log, update DirectAdmin and leave the chmod at 700 (unless you are using suphp)

If it's the apache error, then it's likely you are using suphp, then yes 755 (or 711 preferably) would be needed if no other means are used.

I will be leaving the default to 700, aswith all the default settings, it will have nothing to do with apache, and is a DA tally issue where it's reporting thing which don't need reporting, agian which were fixed some time ago. Update your version of DA to hide the error messages.

John
 
John, we always use the latest DA version and still the problem exists, inspite of pucky's 'solution'.
 
I was just going through the code and found the call to the same check when a User views the pop page.. I'll make it "quiet" as well.

John
 
Back
Top