# Upgrading postfixadmin breaks postfixadmin! [SOLVED]

## NotExcessive

I've just run the upgrade for postfixadmin from 2.1.0 to 2.1.0-r1. The installation went normally, and the parameters in the configuration file remain unchanged. However, when I now point the browser at http://localhost/postfixadmin/admin/list-admin.php I get the message

```
Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

Fatal error: Unknown: Failed opening required '/var/www/localhost/htdocs/postfixadmin/admin/list-admin.php' (include_path='.:/usr/share/php5:/usr/share/php') in Unknown on line 0
```

I'm not sure what's going on here. Can anyone tell me where it's broken?Last edited by NotExcessive on Wed Apr 16, 2008 2:49 pm; edited 1 time in total

----------

## elgato319

Could you post the parts from error_log?

----------

## NotExcessive

 *elgato319 wrote:*   

> Could you post the parts from error_log?

 

I can't see any messages resulting from this in any of the log files. Is there anything specific?

----------

## elgato319

 *Quote:*   

> failed to open stream: Permission denied

 

made me curious...

list-admin.php tries to include some files first

```

require ("../variables.inc.php");

require ("../config.inc.php");

require ("../functions.inc.php");

```

maybe emerge didn't set the right permission on the new files

could you check that?

----------

## NotExcessive

 *elgato319 wrote:*   

>  *Quote:*   failed to open stream: Permission denied 
> 
> made me curious...
> 
> list-admin.php tries to include some files first
> ...

 

I changed them from 640/640/750 to 777/777/777 respectively (don't know if that's what they should be) but there's no difference.

----------

## NotExcessive

Solved it by removing postfixadmin completely and re-emerging it, then just doing a brute-force approach and chmod -R 777 the whole postfixadmin directory. Might not have been politically-correct but it now doesn't crash. Problem is even though I can now create a mailbox, and it shows up in my virtual user table in the SQL database postfix has, it doesn't actually create the mailbox itself, but that's for another thread.

----------

## magic919

Postfix creates the maildirs on first use.  That's how it should work.

----------

## NotExcessive

 *magic919 wrote:*   

> Postfix creates the maildirs on first use.  That's how it should work.

 

Yes, I know, but I'm using maildrop as the LDA in a Postfix/Dovecot/DSPAM/Squirrelmail setup with virtual users. I know maildrop can't create mailboxes, and I never had any scripts for maildrop to do so (maildroprc is basically empty), so I'm assuming that postfixadmin did that. It's been a few weeks since I've added domains and users to the system via postfixadmin. It used to create new mailboxes, but now it doesn't. I can't find anything that's obviously changed, so I'm a bit stumped on where to look.

----------

## magic919

I didn't think Postfixadmin could create any mailbox.   If you really want a mailbox then I'm not sure, but if you want a maildir you can use maildirmake - comes with Courier I think.

----------

## NotExcessive

 *magic919 wrote:*   

> I didn't think Postfixadmin could create any mailbox.   If you really want a mailbox then I'm not sure, but if you want a maildir you can use maildirmake - comes with Courier I think.

 

That's what's got me wondering now - I never *ever* had any scripts running for maildroprc, so maildirmake was never ever called by it. maildrop cannot, unless I've missed something, create mailboxes without a script to do so. And yet, a couple of weeks ago, I added a new domain and a new user, using postfixadmin (I think it was 2.1.0 but now of course it's 2.1.0-r1 from memory) and the default maildirs promptly appeared, the welcome message got delivered, and it was off and running. In fact, the system has been like that since I built it about two years ago. Never missed a beat.

Now, the maildirs don't get created, and of course all I see is an error message in the queue stating that maildrop has had a brain-fart from a dot-lock error, which was to be expected, seeing as how the mailbox wasn't there to deliver the welcome message to.

So..... if postfix doesn't create a default maildir because the transport has been changed from its built-in 'virtual' to 'maildrop', and maildrop can't create it either, since it has no inbuilt functionality to do so, then how the hell did this thing ever work in the first place? The only things that have happened since my last successful "add mailbox"  have been: I've upgraded to 2.1.0-r1, somewhere along the line I upgraded php, and about a week or so ago, I accidentally buggered the /etc/postfix/main.cf file because I wanted to increase the message limit size, and I used Webmin to edit the file, and unfortunately Webmin butchered the file upon saving and nothing ran. I replaced the buggered file with a backup copy, but I can't see any difference to the settings. Gut feel tells me, however, that it must be the main.cf file that's responsible for the change, if postfixadmin never did the create maildir thing in the first place.

Have to admit I'm head-scratching mode over this one.

----------

## stealthy

I didn't quite feel comfortable doing 777 so I just changed ownership from root:root to apache:apache of postfixadmin directory.

----------

## NotExcessive

That might be an idea. I'm building a new mail server soon (less $ in electricity to run it) and so if I strike this problem again on the new installation, I might try that approach.

----------

