vicigeeksimple guides
Browse
Back to Bugs

VICIdial recordings · Apache · Linux permissions

Recordings show Access forbidden: check the parent folder permissions

A recording link returns 403 Forbidden. If the web server cannot traverse /var/spool/asterisk, chmod 755 /var/spool/asterisk restores ordinary list and traversal permissions on that directory.

Direct solution

  1. Restore access to the parent directory

    For a confirmed traversal denial on /var/spool/asterisk, save its current mode, then run this as root on the recording server.

    Before you use it
    Save the existing mode and confirm this directory is the filesystem traversal blocker. Use the recording server, which may be a separate host in a cluster.
    Direct solution — run as root after confirming the cause
    chmod 755 /var/spool/asterisk
    Reader-run example · not executed for this guide

    This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.

    Success looks like
    The directory has the intended permissions and the same authorized recording link opens without the filesystem permission error.
    Stop if
    If the command fails or the recording still returns 403, use the actual log message to identify the remaining cause.
    Expected observation
    For an ordinary directory without special mode bits, the mode is 755 (drwxr-xr-x). Retry the protected recording link to verify the actual result.
    If this check fails
    If access is still forbidden, inspect the new log entry and continue with the checks below. Repeating chmod will not repair an Apache authorization denial or an unreadable child file.

Source and affected scope

Recording is not Accessible

Forum date
August 1–5, 2014; follow-up March 8–9, 2017
Source checked
November 9, 2026
Reported version
Original report: ViciBox 5.0.3, VICIdial 2.10-448a, build 140706-0927. Later report: VICIdial 2.9-441a on CentOS 7.
Guide updated
2026-11-09
  • Recording URLs served by Apache from /var/spool/asterisk/monitorDONE when the web-server process lacks permission to traverse a parent directory.

Before you start

  • An authorized root shell on the server that stores and serves the affected recording.
  • The exact failing recording URL, the corresponding file, and the active Apache error log. Save the original directory mode before changing it.

Diagnose the reported problem

  1. Step 1Save the current mode and inspect the path

    Record the first command's output before applying the solution. namei shows permissions and ownership along the directory path; if namei is unavailable, inspect those directories with your system's equivalent tool.

    755 gives the owner read, write and traversal permissions; group and other local users can list and traverse this directory. It leaves ownership and the modes of recording files and child directories unchanged. Existing HTTP access controls still apply.

    Before you use it
    Run on the recording server and retain the original mode for rollback.
    Read-only permission checks
    stat -c '%a %A %U:%G %n' /var/spool/asterisknamei -l /var/spool/asterisk/monitorDONE
    Reader-run example · not executed for this guide

    This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.

    Success looks like
    The output identifies the directory mode and permissions on its parent path. Compare access with the web-server account's actual user and groups.
    Stop if
    A missing path, alternate recording location or symlink target must be resolved before applying the shown command.
    Expected observation
    You know the original numeric mode and which parent directory prevents the Apache process from reaching monitorDONE.
    If this check fails
    If this is a symlink or uses extended ACLs or special mode bits, inspect that configuration and save it before changing permissions. A different blocker needs its own correction.

  2. Step 2Match the error to its cause

    Open the failing recording link once and inspect the corresponding Apache error-log entry. A filesystem permission or missing-search-permission error supports checking directory traversal. A message such as client denied by server configuration points to Apache's access rules instead.

    Confirm that the requested file exists beneath the configured /RECORDINGS/ alias. Directory traversal, child-file readability, alias mapping, Apache authorization and SELinux policy are separate checks.

    Expected observation
    The error names the path and distinguishes a filesystem permission denial from an HTTP access-control denial.
    If this check fails
    If there is no matching request in this server's log, check which host serves the recording before changing anything.

Correct the confirmed cause

Use this branch only when your diagnostic observations match the affected scope above. The lab result states which outcomes were actually tested.

  1. Step 3Retry the recording after the permission change

    Apply the direct solution only for the confirmed parent-directory problem. chmod takes effect immediately; this command does not require an Apache or Asterisk restart.

    Reopen the same recording through the normal authorized interface. Check that it plays or downloads as expected, then inspect the new error-log entry if it still fails.

    Keep the existing authentication and IP restrictions. For Apache 2.4, review the active Require rules rather than copying the thread's Apache 2.2 Order/Allow examples. The original ViciBox discussion mentions /etc/apache2/conf.d/vicirecord.conf; find the configuration actually loaded by your installation.

    Expected observation
    The authorized recording request succeeds and the filesystem traversal denial no longer appears.
    If this check fails
    If 403 remains, inspect the child path and file, active alias and access rules, and any SELinux denial. Do not broaden permissions recursively or disable access controls to guess at a fix.

Verify the outcome

  • Repeat stat on /var/spool/asterisk and compare the owner, group and any special mode bits with the saved state.
  • Confirm that the exact recording plays or downloads through the normal protected link; a successful chmod exit alone is not proof.
  • Confirm that the relevant Apache error is gone and existing restrictions still reject unauthorized access.

Recover or roll back

  • Restore the exact original numeric mode recorded before the change. For example, only if it was 750, use chmod 750 /var/spool/asterisk. Preserve any originally recorded special bits and ACL configuration.
  • Retry the normal recording workflow and compare the error log. This guide changes no Apache configuration and no child-directory or recording-file permissions.

Screenshot evidence

No native screenshot is attached to this guide.

Actions to avoid

Do not use chmod -R, chmod 777, or open recording access to everyone. This correction changes one directory; it does not replace the site's existing recording access controls.