Illegal file access: the file is not in the list of allowed files.

[dreaken667]

I have been wresting with this error for quite some time now and have gone through this forum already searching for answers. A lot of the suggestions concerning this error suggest the need to search for the files first, so let me explain where I am receiving this error first.

Run quick activity, agent or custom report from main screen, go to Answered details, click the magnifying glass next to call. From here I have tried several ways to reach the recording:
1. Click the call recording link at the bottom of the Call Detail tab
2. Click the QA tab followed by the call recording link in the new window
3. Click the QA tab, then add the call recording to a batch job. Then go to that job, list calls, click the listen to call icon and then the call recording link.

All of the above leads to the same error: "Illegal file access: the file is not in the list of allowed files."

I have tried adjusting default.monitored_calls and audio.server in QueueMetrics and I can get it to display the links as both LocalFiles and LocalFilesByDay, but the same error appears when clicking the link. The call recordings are on the same machine as QueueMetrics. I've even tried creating a bind mount for /var/spool/asterisk/monitor at /usr/local/queuemetrics/webapps/queuemetrics-14.03.1-750/monitor and adjusted QueueMetrics settings accordingly. It still provides a link, but I get this error when clicking it. QueueMetrics is running as root and /var/spool/asterisk/monitor has 777 permissions right now and I still get this error.

We upgraded the system to version 14 to take advantage of some of the new features and everything else is working great, but we can't access call recordings at all now.

Does anyone know how to make this work properly?

[QueueMetrics]

Look at the file names - are there any special characters in them? especially spaces and plusses (+).

That error is meant to avoid people hacking the system and accessing to other recordings through QM if they have not seen the page first.

[dreaken667]

Yes, the filenames do have a + in them. This is because of the caller ID of the caller coming in as +1NPANXXXXXX, so the filenames turn out to be like this: q-713-+17879425688-20140520-071636-1400588142.39217.wav

What would you suggest to get around this issue?

[QueueMetrics]

Easiest - rename the files.

[dreaken667]

For the sake of others having this issue, I was able to resolve the problem. This particular system is utilizing FreePBX 2.11.0 & asterisk 10.12.3 in case that is relevant. Here is how I was able to resolve the problem:

Add the following to /etc/asterisk/extensions_custom.conf:

Code: [Select]

[from-pstn-custom]
exten => _X!,1,GotoIf($["${CALLERID(num):0:1}" = "+"]?plusstart:noplusstart)
exten => _X.,n(plusstart),NoOp(Changing Caller ID number from ${CALLERID(num)} to ${CALLERID(num):1})
exten => _X.,n,Set(CALLERID(num)=${CALLERID(num):1})
exten => _X.,n,Set(CALLERID(ANI)=${CALLERID(num)})
exten => _X!,n(noplusstart),NoOp(Caller ID does not need adjustment)
Then load the new dialplan code with:

Code: [Select]

asterisk -rx 'dialplan reload'
This will fix all calls going forward. To fix all calls retroactively I had to rename the existing call recordings like so:

Code: [Select]

for d in `find /var/spool/asterisk/monitor -mindepth 3 -type d`;do
    cd $d;
    for i in *.wav; do
        mv $i ${i/+/}
    done
done
The last thing I did was not actually necessary, but I did it to maintain consistency. This will strip the + from all existing calls in the database:

Code: [Select]

echo "update queue_log set data2 = replace(data2, '+', '') where data2 like '+%'"|mysql -uroot -p queuemetrics
I hope this saves someone else a headache.

[QueueMetrics]

Thanks! Can I add this to the User manual? please send an email to our support line so we know how you want to be credited in the manual.

[dreaken667]

Go ahead. I'm not interested in being given credit as long as it saves someone else the trouble.

[QueueMetrics]

Thanks I will!

[ardyhash]

Firstly, thank you Dreaken667 for the excellent writeup, I have been struggling with this for sometime myself and was surprised that Queuemetrics didn't have a solution to offer.

Secondly, I'm afraid I'm still struggling. After adding the proposed dial plan to /etc/asterisk/extensions_custom.conf (I think there may be a typo in the original post, it says to add the dial plan to /etc/asterisk/extension_custom.conf (no s, singular not plural)) and reloading the dial plan, everything remains the same. Watching the logs I can see that the added lines are never executed.

We are using SIP trunks, though from what I gather that should not make a difference, when a call comes in the logs show (DID#)@from-pstn is executed, and based on the messages it is not the dial plan added to extensions_custom.conf.

Do you have any pointers as to what I may be missing?

Thank You,

~ardy

[ardyhash]

Thanks again for the excellent solutions (moving forward, fixing the past, and the one-liner for database consistency between past and present), although for whatever reason it wasn't working for me. After some googling I learned of the "from-pstn-e164-us" context which is already written into freepbx, specifically for the purpose of removing the +1. Simply putting your trunks in that context will remove the +1, and the best part about this solution is no need for a shell, it can be done in the GUI.

Alternatively, for those who wish to use your custom context but ran into my problem (the context doesn't stick), they may choose to name the context whatever they wish, and simply place the trunks into that context which they named.

The offices are all closed now, so if I run into any problems tomorrow I'll post once I learn of them, though I don't foresee any issues.

Once again thank you for the excellent writeup, I had been revisiting this annoyance every so often over the past months and was very excited to find this thread.


P.S. From what I gather the reason your method was not working for me may have been, and I'm not sure here, the order of the dial plans in memory. If it matches another dial plan first thats what it will go with.

[dreaken667]

You are correct, ardyhash. That was a typo on my part. I've updated it to reflect the correct filename (/etc/asterisk/extensions_custom.conf). If you used the incorrect name then the dialplan would not have been included properly and would never have been executed as you saw. You are also correct that you could name the context whatever you want and then set your trunk to drop the calls into that context, although the context would need a slight adjustment:

Code: [Select]

[custom-inbound-context]
exten => _X!,1,GotoIf($["${CALLERID(num):0:1}" = "+"]?plusstart:noplusstart)
exten => _X.,n(plusstart),NoOp(Changing Caller ID number from ${CALLERID(num)} to ${CALLERID(num):1})
exten => _X.,n,Set(CALLERID(num)=${CALLERID(num):1})
exten => _X.,n,Set(CALLERID(ANI)=${CALLERID(num)})
exten => _X!,n(noplusstart),NoOp(Caller ID does not need adjustment)
exten => _X!,n,Goto(from-pstn,${CALLERID(num)},1)
Without that last line to pass the call off, the call would not progress any further. For this example, you would need to adjust your inbound settings on your trunk to have:

Code: [Select]

context=custom-inbound-context
instead of:

Code: [Select]

context=from-pstn
In my case I just needed to strip the + and not the +1, so setting the inbound context to "from-pstn-e164-us" was not a viable  option for me but it could work for others.