Call Recordings unable to write new file - Permission Error

Good Morning,

Today I came in and my boss was unable to find a recording she was looking for. After looking into it, it seems that no calls had been recorded since 4:30am. I followed a call through the CLI in asterisk and saw the following:

-- Executing [recordcheck@sub-record-check:16] NoOp("SIP/Digium_VoIP1-00000a8e", "Starting recording: in, 2674951179") in new stack
-- Executing [recordcheck@sub-record-check:17] Set("SIP/Digium_VoIP1-00000a8e", "AUDIOHOOK_INHERIT(MixMonitor)=yes") in new stack
-- Executing [recordcheck@sub-record-check:18] Set("SIP/Digium_VoIP1-00000a8e", "__CALLFILENAME=in-2674951179-3478152765-20170216-084534-1487252734.317278") in new stack
-- Executing [recordcheck@sub-record-check:19] MixMonitor("SIP/Digium_VoIP1-00000a8e", "/var/spool/asterisk/monitor/2017/02/16/in-2674951179-3478152765-20170216-084534-1487252734.317278.wav,ai(LOCAL_MIXMON_ID),") in new stack
  == Begin MixMonitor Recording SIP/Digium_VoIP1-00000a8e
    -- Executing [recordcheck@sub-record-check:20] Set("SIP/Digium_VoIP1-00000a8e", "__MIXMON_ID=0x7f23480a2510") in new stack
[2017-02-16 08:45:34] WARNING[16995][C-000005f0]: file.c:1314 ast_writefile: Unable to open file /var/spool/asterisk/monitor/2017/02/16/in-2674951179-3478152765-20170216-084534-1487252734.317278.wav: Permission denied
[2017-02-16 08:45:34] ERROR[16995][C-000005f0]: app_mixmonitor.c:615 mixmonitor_save_prep: Cannot open /var/spool/asterisk/monitor/2017/02/16/in-2674951179-3478152765-20170216-084534-1487252734.317278.wav

I simply did chmod 777 /var/spool/asterisk/monitor/2017/02/16/ and made a test call and it worked right away. What could have caused this? Any ideas? Should this be posted on Asterisk Forum perhaps?

Thanks

From the console (logged in as “root”) start with a “fwconsole chown” and “fwconsole chmod” to start.

We don’t know what the permissions were on the directoes before, so it’s hard to say what the problem actually is, but it’s safe to assume the directory was owned by “root”.

I’m on FreePBX 12 Distro 6, so its amportal still. I used amportal chown, but not chmod. The thing is the folder is created daily, I highly doubt anybody changed the folder permission today. (I had recordings at 4:30AM, but nothing after 5AM). The only thing I can think off is we have sales come in at 4:30 and used the “sales override” to open up the phone lines. Really weird IMO.

Here is what it was:

drwxrwxr-x 2 asterisk asterisk  6000640 Feb 14 21:21 14
drwxrwx--- 2 asterisk asterisk  9936896 Feb 16 08:22 15

I already changed what i was this morning, but if I remember correctly, it was

drwx------ asterisk asterisk Feb 16

Interestingly, the files recorded before this problem, but today, around 4:30 AM, have permissions of 777, but new files created after I fixed the problem, have rw-rw----. It is working as expected, tonight at midnight I’m going to watch it create a new folder and check the permissions.

That’s really weird, because the system should have been able to write the files into that directory unless your Asterisk is not running as the asterisk user.

Check to make sure you are running asterisk as the asterisk user and that the web server on the machine is also running at asterisk… Also, check your /etc/group file and see what groups asterisk is in.

There’s something hinky going on. Your asterisk user should have access to the entire /var/spool/asterisk directory tree.

If it turns out that the problem is that the file was there, but not accessible from the webserver (UCP or whatever you are using) then the problem is in the web server ownership.

The file was definatley not there, I saw that there were only call recordings made from 4:30/5AM when I got in at 9AM. I will check all that, and again, those permission are from memory, could be wrong. Since I am aware of the issue, my plan is to see what permissions the directory is created with tonight. For today, I just needed it fixed ASAP lol.

PS: This is an official Distro install, I didn’t really modify much, so it should be asterisk user for everything. I did upgrade us to the following, but I am rolling back to Ast 11 to to calls dropping. This issue appeared after upgrading the Disto/Switching to Ast 13.

[root@voip2 fpbx]# cat /etc/schmooze/pbx-version
6.12.65-32
[root@voip1 asterisk]# asterisk -V
Asterisk 13.9.1

These two versions are very very old.

chmod is not a valid arg for fwconsole. You only need fwconsole chown.

Unfortunately, if I upgrade any further, the ARI Recordings interface is completely removed. The new Interface doesn’t seem to be able to find recordings in the old format/location (we have like 8K files under /var/spool/asterisk/monitor/*), and we built custom code which search’s the old recordings interface via a custom URL. Once I ran into that issue, I realized we need to wait about a year until all the old recordings are no longer needed and we can look into starting to migrate users to use the new recordings interface, but thats a little off topic.

Also, the new interfaces are not a whole lot better, we generally search for calls via a phone number, not by date/extension. This way we can see all calls a certain number has called in from, as they may have spoken to different reps on different dates/times. Seems the new interface’s want you to search by date/extension.

@lgaetz I had never heard of that command either lol, thank you for clarifying.

So use CDR Reports in UCP (EG Call History). It does exactly what you want.

@tm1000 The first thing the UCP wants is for me to select an Extension unless I am missing something. I want to search the entire recordings based on Phone Number. Actually, the best interface so far has been the CDR Reports Interface to replace the ARI Interface.

The only issue is we have custom URLS to search the ARI Interface, and I’m trying to figure out something similar for CDR if you know of any tricks let me know!

Just FYI, the directories have been created correctly the past few days w/

chmod 770 Permissions and owned by asterisk:asterisk and all is well. Chalking that up to the random glitch category.

sorry did not read it was about ARI.