FreePBX call recording not working can mean several different things. The system may not create a file, may save it somewhere unexpected, or may record successfully while playback fails. Start by identifying which part of the process is broken.
Call recordings can contain sensitive customer, payment, health, or employee information. Therefore, avoid broad permission changes, public file sharing, and unnecessary downloads. Capture evidence first, test with a controlled call, and protect every copy.
Define the recording problem before changing settings
Ask what the caller and administrator actually observe. A missing recording, a silent file, an unavailable playback button, and a failed download point to different causes.
- No file exists: investigate the recording policy, call path, dialplan, and recording application.
- A file exists but has no audio: check media negotiation, codec handling, and whether the call used an unexpected path.
- The file exists but cannot play: check format, ownership, file integrity, browser behavior, and the FreePBX retrieval layer.
- Only some calls fail: compare extension, queue, ring group, inbound route, outbound route, trunk, and call direction.
Record the date, time, caller direction, extension, destination, trunk, and approximate call duration. Do not place real customer information in an issue title or shared troubleshooting document.
For a clear diagnosis, treat FreePBX call recording not working as a symptom rather than a conclusion. A structured workflow helps prevent guesses from becoming configuration changes. The Google SRE troubleshooting guidance also emphasizes evidence, hypotheses, and controlled tests.
Check FreePBX recording policies and call paths
FreePBX recording behavior depends on where the call enters and how it reaches its destination. An extension can have one policy, while a queue, ring group, or route applies another setting.
Review recording settings at each relevant layer. Depending on the call, that may include the extension, inbound route, outbound route, queue, ring group, conference, or feature code. Look for settings such as always record, record on demand, never record, or inherit.
When a policy says “on demand,” recording may not begin until a user activates it. The call may then produce a partial file. Confirm whether the test user knows the recording feature code and whether the dialplan permits it.
Next, compare one failing call with one successful call. Use the same extension and destination when possible. Change only one variable during the test. For example, test an internal extension call before testing an external trunk call.
Trace the route without editing the dialplan
Inbound calls can pass through a DID, time condition, IVR, queue, or ring group before reaching an agent. Outbound calls may use a route and trunk with different media behavior. If the call bypasses the expected destination, its recording policy may also differ.
Use call detail records and Asterisk logs to identify the channel path. The guide FreePBX IVR call troubleshooting explains how to trace an inbound call through its dialplan without making blind edits.
Verify recording storage paths and disk capacity
FreePBX usually stores recordings on the PBX server, but the exact path depends on the recording type and system configuration. Do not assume that a file is missing because it is absent from one directory.
Check the recording configuration and identify the path used for the specific call. Then search carefully by call date and extension. On a Linux system, an administrator might inspect directories and file metadata with read-only commands. Confirm each command against the server and distribution before running it.
Disk capacity is another common cause of FreePBX call recording not working. A nearly full filesystem can prevent new recordings, temporary files, database updates, or web playback. Check the relevant filesystem, not only the root filesystem. Also review inode availability, because a filesystem can run out of file entries before it runs out of storage space.
Do not delete old recordings during diagnosis. Instead, identify retention rules, backup status, and business ownership. If recordings consume unexpected space, export or archive them only through an approved process.
If the PBX uses a mounted share or separate recording volume, verify that the mount is present and writable. A disconnected mount can make a path appear empty or redirect writes to the underlying local directory. That situation requires careful handling before restarting services or remounting storage.
Check ownership, permissions, and security boundaries
Recording files need suitable ownership and permissions. The web interface, Asterisk process, and maintenance jobs may not use the same account. A change that lets one component read files can expose recordings to other users.
Inspect the owner, group, mode, parent-directory permissions, and any access-control rules. Look for a difference between a working recording and a failing recording. Compare timestamps and file sizes as well.
A file with zero bytes suggests a write or call-finalization problem. A normal-sized file that the interface cannot read suggests a retrieval or permission problem. Large files with short durations may point to a media or hangup-finalization issue.
Do not use commands that recursively change ownership or set world-readable permissions unless a qualified administrator has confirmed the exact requirement. Preserve the current state before changing it. Record the original owner, group, mode, and path so you can roll back.
Also review who can access recordings through FreePBX, shared folders, backups, and administrator accounts. Recording access should follow business need. Use encrypted transport and approved storage when moving a sample for analysis.
Investigate codecs and the audio path
A codec converts audio between a usable signal and a digital format. FreePBX may record the media that Asterisk receives, while the endpoint or trunk negotiates a codec separately.
Check whether the failure affects internal calls, external calls, or only one provider. Compare the negotiated codec and media direction in a working and failing call. A recording problem that appears only on one trunk may involve provider media, transcoding, or a different channel type.
Silent recordings require special care. Confirm that the live call has two-way audio before blaming the recording function. If the call itself has missing audio, investigate RTP flow, NAT, VPN routing, and firewall behavior. Recording cannot capture media that never reaches the recording process.
Read the relevant Asterisk documentation for channel, media, and recording concepts before changing advanced settings. The official Asterisk documentation is the appropriate reference for version-specific behavior.
Do not force a codec across the entire system as a first response. Codec changes can affect trunks, phones, bandwidth, CPU use, and other calls. Test a controlled path and confirm provider compatibility before adopting a change.
Separate playback and retrieval failures from recording failures
Sometimes FreePBX call recording not working is actually a browser, interface, or retrieval issue. First confirm that the expected file exists and has a plausible size. Then test playback through the intended FreePBX page.
Check whether the recording appears in the call detail record. If it does not, compare the call identifier, date, extension, and recording filename. A mismatch can occur when a call transfers, enters a queue, or creates multiple channel records.
If the browser shows an error, test with a controlled administrator account and a supported browser. Do not download recordings to an unmanaged computer merely to test playback. Instead, use an approved workstation and delete temporary copies securely.
File format matters too. A browser may not play every format directly, even when the file is valid. Use an approved player or conversion process. Keep the original file unchanged, and protect converted copies with the same access controls.
For queue or transferred calls, confirm whether the system creates one file, several linked files, or separate segments. Retrieval behavior may differ from ordinary extension-to-extension calls. Review the call record and logs before assuming that a segment is lost.
Use a safe test and document the result
Run one short test call with authorized participants. Note the exact start time, caller direction, extension, route, destination, and whether recording was automatic or user-triggered. Avoid recording real customer conversations during testing.
- Confirm the policy that should apply.
- Place the controlled call.
- Check the call detail record.
- Locate the file and inspect its timestamp and size.
- Test retrieval through the approved interface.
- Compare the result with a known-good call.
- Document any single configuration change and its outcome.
Keep logs and samples inside approved systems. Redact phone numbers and names when sharing evidence. Set a retention date for diagnostic copies, and remove them when the investigation ends.
If the issue involves a trunk or external call, compare the route and media details with the general checks in FreePBX outbound call troubleshooting. That comparison can reveal whether the recording symptom follows one trunk.
When to escalate the recording problem
Escalate when recordings contain regulated information, storage is failing, permissions are unclear, or the issue affects many calls. Escalation also makes sense when logs show repeated Asterisk errors, database inconsistencies, or unexplained service restarts.
Provide a timeline, affected call types, policy settings, storage path, disk status, file metadata, and sanitized log excerpts. Do not send full recordings unless the recipient has authorization and a secure transfer method.
FreePBX call recording not working becomes easier to isolate when you separate policy, media, storage, and retrieval. Tech Rescue Ops LLC can provide remote assistance when the PBX needs careful log review, permission analysis, storage recovery, or a controlled configuration change.