Syadmin module has permission denied to mkdir() upon fresh install of latest version

I just downloaded the “STABLE SNG7-FPBX-64bit-1707-1” from here: , created bootable USB and installed the Freepbx using default options, specifying the root password at very beginning. It took alot of time at 571/649 which is RPM as per my study on this forum.

After installation, I rebooted as per instruction by Freepbx and once the system rebooted, it went to root prompt but showed an error in red before that saying “Module/Freepbx/sysadmin : mkdir() permission denied”. This is a little annoying as earlier I used to install Freepbx without any such problems and things went well.

Can anyone guide about this?

The same problem even on the 2nd fresh install…

Error From Module FreePBX\modules\Sysadmin: ‘mkdir(); Permission denied’

After this, when I login from Freepbx UI from browser, it gets logged in. But in User manager, I am not able to create new user. There is no “Add User” button.

In the Users tab of User Manager change the directory type from “All Directories” to “PBX Internal Directory” - the “Add” button will appear.


If you wait a minute or two do you still have the problem?

It sounds like one of the problems I had here

This is because you are logging in to system using SSH before MariaDB has had a chance to start, if you give it a minute or two more you won’t get this message.

When you logon using SSH you get a MOTD-like message from FreePBX and the database has to be up for it no to fail in this way…

Good luck and have a nice day!



Why is that necessary? In early version of Freepbx, we didn’t need to do this and it worked well. Seems the new version has broken something unnecessary.


I am just rebooting the system and then login from the same pc. No SSH is done. It is strange to have such issue which was not faced early.

It’s necessary because we now support multiple directories. So you could have two active directories. One ldap and. A local directory for users. You need to select which directory to add users to. This is how more advanced products work like atlassian crowd.

You are logging in as root on the system itself?

If so and if you don’t the same problem when you wait a minute or two before logging in, it is the same problem.

As for facing it early or not, on my test system which is older hardware MariaDB takes about 16 seconds to start IIRC. If your system is faster than my test system it surely takes less than that so this is not something that you will get each time if you don’t immediately log on.

Should that problem be fixed eventually? Yes but there are more pressing issues…

Have a nice day,



Yes I am logging in as root on the system itself after fresh install. That is why this behavior is really strange for me.

I haven’t tried waiting a minute or two as I didn’t get a chance to work on this again, but I’ll give it a try.

Regarding the 16 seconds to start IIRC and system speed, I don’t think it is so because why didn’t it happen with the latency version of Freepbx on the same machine? Also, I have Macbook Core i5 and it never raised such exception with the previous version of Freepbx.

Even if such problem is coming, will it have any effects on the Analog calls coming into the system? I am really concerned about it as this behavior may have any other impacts as well.

If you are logging in on the command line before the startup has completed this is expected behavior… To me it is a bug, something should eventually be done about it but there are far more pressing matters to fix…

16 seconds is what I believe systemd-analyze blame (IIRC) reported on my test/home system which is a Core 2 something so your Core i5, whatever its generation is, is definitely more powerful. That 16 seconds on my system might not be all CPU related though but IO related and while the hardware is old the hard drive is pretty good on that system I believe (most likely the best WD Caviar Black of the capacity I wanted I could get at the time).

You can try in on your system as well once you has sure the boot has fully completed…

It might be a new “feature” of FreePBX 14 or changes in the boot process (there were some recently on the FreePBX distro) which make it easier to happen…

No… If you are having the same problem that I have you are simply connecting to the system before the boot process has completed… Would you prefer not to be able to logon before the boot process has completed?

What fails when you logon this early on the system has no impact on how well things work after…

You mention having Analog hardware, depending on what it is you might have to disable a service at boot that was erroneously turned on and had negative impacts for people which were both using the hardware it it meant for (Sangoma cards) and not using them. I do not know if it has been fixed in the most recent images…

Have a nice day!


This is only there because FreePBX hasn’t completely started yet. I’ve set up SNG7 so it brings up the login prompt BEFORE everything’s started, because FreePBX can take a while to start all its other services.

If you just sit there for 30 seconds after the login prompt appears, and THEN try to log in, you won’t get the error.

I hear an echo… :stuck_out_tongue_winking_eye:

Kidding Rob… This is essentially what I had concluded in another thread and Andrew had confirmed…

It would be nice if the MOTD-like stuff that gives this error would check if FreePBX or at least MariaDB has started before trying to access the database but there are other things that I am more looking forward to than a fix for this…

Have a nice day Rob!


1 Like

It’s not related to MariaDB however.

Long story short @xrobau wanted to turn on tracebacks to be able to fix this and I said no…

I was wrong. We just enabled traces so we should be able to figure out what’s going on shortly.

I say it’s not MariaDB related because if MariaDB wasn’t running it wouldn’t even get to executing something in sysadmin. FreePBX has to bootstrap first and in there it queries the DB for all of the configuration options before it even gets to executing a module’s subcode.

The other error message I got in the thread I referred to earlier seems to refer to database handling code in FreePBX…

You are right however that the error message mentioned in this thread does not seem to be directly related to the database, I cannot say if it is indirectly so I trust you on this…

Have a nice day!


edit: for reference this is the other error message I was talking about: System updates gets exception even after reboot . I mentioned the problem mentioned in this thread in that message too but did not actually post the exact error message.

1 Like