HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Server Operation (http://www.howtoforge.com/forums/forumdisplay.php?f=5)
-   -   Postfix/Courier Maildirsize issue (http://www.howtoforge.com/forums/showthread.php?t=45245)

philefluxx 23rd April 2010 01:02

Postfix/Courier Maildirsize issue
 
Hey guys,
I just recently migrated my Postfix/Courier mail system off of a failing server. On the new server Im running into a issue with the maildirsize. Through some research it appears to be an issue with 32bit OS vs 64bit. Basically what happens is in my MySQL users table I have a user set to a 4gig quota. Ive gone into the users mail directory and modified the maildirsize to reflect the same 4gig's. When the user imap's his box the maildirsize file is changed back to 2gigs. Ive tried removing the maildirsize and allowing it to be recreated once a new email comes in and it still writes it out to 2gig size limit. I have gone from a 64bit system to a 32bit system. Is this a true issue related to 32bit OS? Is there a work around? Thanks guys!

Mark_NL 23rd April 2010 09:17

2gb is the maximum size for a 32bit system. You should change to 64bit

philefluxx 23rd April 2010 20:05

So if I where to change:

virtual_create_maildirsize = yes

to:

virtual_create_maildirsize = no

Then if I wish a user to have a maildirsize limit I just create the file for them would this resolve any quota issues?

RogueCoder 26th April 2010 13:09

I'm not positive here, but I believe it is setting it to 4GB, but when it returns the maildirsize it can only send back the integer max (2147483647) which equates to 2GB. The 64 bit system changes the integer max I think which is why it is fixed.

philefluxx 26th April 2010 17:17

Unfortunately I do not have another server to launch a 64bit system and this mail system needs to stay up at all times. So what I'm hoping to find is a work around until maybe at a later date I can move things to a 64bit OS. So Im curious as said above, if I change the creation of the maildirsize file to no and remove it will this have any other effect on the mail boxes other than unlimited space? Then should I need to limit a directory to 2gigs I can just manually create a maildirsize file.

topdog 26th April 2010 23:41

Use a decent imap server like cyrus, each mail is stored in its own file and quotas are built in you will not have these issues.

philefluxx 27th April 2010 00:25

Quote:

Originally Posted by topdog (Post 226601)
Use a decent imap server like cyrus, each mail is stored in its own file and quotas are built in you will not have these issues.

I appreciate the advice, but as stated I do not have another server to use at this time nor can I take down this server. I am just looking for a temporary workaround so I can either a) build a 64bit system or b) use something other than Courier but either way at this time neither of those are a possibility.

Id really just like thoughts or an answer on my work around to remove the maildirsize option. Thanks!

topdog 27th April 2010 01:03

Okay, anyway the 2GB limitation is history on linux 32bit with the advent of LFS, your problem has to be something else.

http://www.novell.com/documentation/...ml/apas04.html

philefluxx 27th April 2010 18:55

I think the issue is with Courier and the 32bit OS, not just the OS itself.

philefluxx 27th April 2010 20:04

So what Ive decided to do is:


virtual_create_maildirsize = no


Ive then modified the existing maildirsize file to reflect 4gigs. This resolved the issue on the client side, but I believe that the maildirsize file will no longer be updated and my Quota Reports will not be accurate, though I noticed on the quota_notify report my user's quota did go from -75 to -37. I will be curious in the next couple days to see if this value increases. If so then I think Ive found a decent work around.


All times are GMT +2. The time now is 17:38.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.