Recording files are 0 bytes when downloaded but are normal size on OS

Hello everyone,

Here is some background information on this odd issue. The normal recordings folder on the system (/var/spool/asterisk/monitor) is starting to fill up. I wanted to utilize my SAN network and change the folder to one of the NFS folders that I have so I didn’t have to worry about space anymore.

After making a symbolic link to the new mounted directory everything was working well, or so I thought. I noticed that Asterisk was creating new recording files in the proper folders with the proper permissions. However, when I go to download the recordings via CDR/UCP the recording file is an empty file. It is zero bytes and unplayable. If I download the file via FTP the file plays fine and has an actual size. It is only when I download it via the FreePBX GUI that I have this issue.

It makes me feel like it is related to the website somehow but I haven’t noticed anything in access_log, error_log, messages, or Asterisk logs. Everything seems like it is set as it should be.

I know this is usually related to a permission problem, but all of the files and folders have asterisk:asterisk set as the owner and group. If the permissions were not correct then Asterisk would be unable to create new recordings in the first place.

I have done similar methods before with great success, like adding a new hard drive and using a symbolic link to the new drive. This is my first time trying to use NFS though and it is a Windows hosted NFS server (if that makes a difference somehow).

I have tried changing the recording path instead of using a symbolic link too, but that has the same issue.

I appreciate any suggestions,

Thank you! :slight_smile:

How do you mount your nfs , (be very specific)

http://nfs.sourceforge.net/nfs-howto/ar01s05.html

You are probably better off changing the $ASTSPOOLDIR to it rather than trying to bind mount it. If you do that make sure you let asterisk know to buffer those writes to a local directory in asterisk.conf

I was having the share mounted through fstab with the following command

192.168.65.50:/share /mnt/recordingsan nfs rsize=8192,wsize=8192,timeo=14,intr 0 0

Do you believe changing the “$ASTSPOOLDIR” will make a difference to what I am experiencing or is that more of a best practices suggestion when things are working normally?

The FreePBX code will generally use that variable to find out where vmails and monitor files are but it depends on the version you are using, some (very) old ones use hard-coding in their CDR pages. Pretty well anything like that should also force sync and for security , well you need to RTFM there :slight_smile: I believe my link covers it though

The thing is is that I am able to view the recordings and download them just fine. If the recordings weren’t able to be seen by FreePBX then play/download icon wouldn’t appear. It’s just that the downloaded files are empty while the ones on the OS are not (ls -lh shows them greater than 0 and are playable if downloaded via FTP).

From what I read on your link doesn’t suggest any solution for that. Am I missing something obvious?

Bet it’s something dumb because of the symlink and PHP not following it hence why we give you the ability to define the path. I suggest you follow what we have defined by setting the absolute path.

Is setting the path the same as setting the path in Advanced Settings under “Override Call Recording Location” or do they change different settings?

What version of freepbx

It is FreePBX 12.

I appreciate everyone’s input so far, thank you.

I’ve seen this before - you might need to do some userid mapping on your mount and double check your permissions.

It looks like the directory is accessible, but the files are not.

DEEP UNIX STUFF HERE
In a Unix “ls -la” command, the file permissions for the directories and files are important.

rwx = read/write/execute.

The ‘x’ part means that you can ‘cd’ into a directory, while the ‘r’ and ‘w’ means you can read and write to the directory.

If you can read a directory, you can get the file names (because they are stored in the directory data file) but if you don’t have read access on the actual file, you will get a zero-length file when you try to access it. With Unix (unlike Windows) just because you can see a file doesn’t give you any more access to it unless the file’s permissions actually allow you to read the file.

Now, back to userid mapping - if you are accessing the file over NFS and your user number and name mappings are different between the two machines, you could easily find yourself in an inadvertent position where you can read the directory (which you created) and not read the file (since the system created it).

When I was teaching this stuff at UNO, a lot of students had problems getting their heads around the whole Unix file systems permissions thing.

1 Like

Thanks for the explanation.

The odd thing is that for a test I set one of the recording files to 777 and that still ended up downloading an empty file.

The truly odd thing is that I can download and play the files fine via FTP, they are created fine by Asterisk, and their permissions are set properly. It’s just downloading the files via the web GUI has empty files.

I am starting to suspect that there may be something weird with the UID/GID of the NFS share. I think it may have to do with Windows being the NFS server, but it’s only a hunch I have right now.

This is fixed in FreePBX 13. Which is why I asked for the freepbx version

Ok, I will try upgrading and see if that helps.

I spun up a test FreePBX 13 and configured everything I have with the version 12 settings and it appears to have worked.

This is a side question, but do you have any idea how many recordings FreePBX can handle before it starts to get bogged down or is it entirely up to the database?

Thank you all for your assistance.

I have about 11,000,000 recordings on the archive of my phone server. The phone server itself seldom has more a couple days of calls (about 800 per hour).