System deleting voicemail every night from inbox


Not sure how long this has been going on but all of the sudden we are seeing voice mails being deleted every night from the inbox. Only messages stored in Old Messages are not deleted. There is no cron job that I can find that is doing this. Is there some settings I set accidentally??? What might be controlling this. I am on the latest version of FreePBX.


Please double check your cron entries by running the following from the command line:

cat /etc/crontab /var/spool/cron/*

Okay here is the output:

[[email protected] ~]# cat /etc/crontab /var/spool/cron/*


01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
0 0 * * 0 /var/lib/asterisk/bin/ 1
59 * * * * /var/lib/asterisk/bin/freepbx-cron-scheduler.php

the freepbx-cron-scheduler.php is just part of freepbx querying isn’t. I have the setting delete zombies set to one, this wouldn’t cause this would it?


chucknb28409, if I understood you correctly, your voice mails are being deleted every night. This is a very weird situation (especially as there doesn’t seem to be any scheduling involved). What are the chances that there is some malicious activity going on there?


Its also possible that the user reporting it has no idea what they are seeing. I will do some some further test tonight after hours to see if there is something else… Also are deleted voicemails reported in a log, if so which one? If not is this something I can turn on?


How does the user know they’re being deleted? Once a voicemail is acessed it’s moved to the “OLD” file. I wonder if the user is listening to them, they’re moved to “OLD”. The user then, at a later time, tries to access them and finds they’re not in “NEW”.

This is only one user? Are the voicemails being emailed to them? If so, is the block, in voicemail setup checked that causes the VM to be deleted when it is emailed.

Finally, is the user accessing the recordings through the ARI webpage? If that’s the case, they have to remember that accessing via the webpage is the same as accessing them through the phone.

These may all sound silly, but don’t be insulted. In over three years of running asterisk I’ve had just about every user problem I could imagine (and a number I couldn’t…like forwarding a number to itself…).

Sometimes it’s just better to get another set of eyes on the problem.



I am not insulted in any way, I have had my share of clueless users… The behavior you described must be new, I have listened to emails in the ARI interface before and they were not moved to OLD so this must be new behavior, what version did this start?

We are not emailing voicemails at this time. It is a few users reporting a possible issue. They were use to getting lots of voicemails and now they are not getting any. Something I just thought of is the after hours recording, its possible someone fooled with this and now voicemails are not showing up because the night settings are not working.

I just ran a simple after hours test and it is fine except that I cannot access the voicemail (it won’t play). I did a local and calling in from an outside line. The call coming in from an outside line was not playable (I checked the rights and they look identical to the internal voicemail - when I say it is not playable I get a message that a plug in is missing. I checked the settings on 2 different extension and they are both set to .gsm one works and one does not). The local (inside call, extension to extension) call worked fine and was playable. I did not observer the behavior of the message being moved to the OLD box after playing. I am using


Okay this is weird. The external voicemail is now working fine and is not giving me a plug in error. I noticed that someone must have changed something since the orange warning bar was visible on PBX Admin. I will check further…


I think I just discovered the issue with voicemails giving me the plugin error. If I log in as one extension say 414 and then logoff and then log back in as say 413 the system still thinks I am 414. The only way around this is to close the ARI and then go back into it as another extension. Isn’t the logout supposed to completely log out the user (even after the check box remember password is checked) or am I miss understanding the use of the remember password check box.