Solved Scheduled backup failure to mounted SMB target

[JonnyM]

I am backing up to an SMB destination mounted on my 3CX server (the PBX is hosted in Azure, I am using Azure Files). The Linux OS can see the mount and work with the files without any problems, 3CX can see the mount point and the contents of it, and I can successfully create a manual backup to this location. The scheduled backup fails each time and I am emailed this error:

3CX Phone System tried to backup but failed due to the following reason(s):
System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted
--- End of inner exception stack trace ---
at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
at Interop.CheckIo(Int64 result, String path, Boolean isDirectory, Func`2 errorRewriter)
at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
at System.IO.FileSystem.MoveFile(String sourceFullPath, String destFullPath)
at System.IO.File.Move(String sourceFileName, String destFileName)
at BackupRestoreSchedule.BackupJob.RotateFiles(IFilesystem filesystem, Int32 count, String filename)
at BackupRestoreSchedule.BackupJob.Execute(IJobExecutionContext context)

Does the scheduled backup do something differently to the manual backup? In each case I am backing up the license information, custom templates, voicemails and recordings. Any suggestions?

 

[AWS2P]

Hi,
message seems clear, rights are not granted so your backup fails

 

[JonnyM]

That's what I thought initially, but 3CX can read and write to the target without any issues - it can delete existing backups and create new ones when invoked manually. It's just the scheduled job that fails.

 

[AWS2P]

Is it same account used when manually done and scheduled task?
As you have not same behavior, i guess it's not.
Need to wait advice for 3cx staff to be clear on that point.

 

[JonnyM]

I have upgraded to v16.0.3 and the behaviour is the same - error denied to the path reported in the alert email. However, I can see that backup files are being written to the location, they just aren't being reflected in the UI (and possibly aren't being written correctly). As you can see the permissions on this location shouldn't be causing any issues.

pbxexpress@vm1b861875d4:/mnt/3cxbackup$ ls -al
total 464488
drwxrwxrwx 2 root root        0 Sep  2 22:08 .
drwxr-xr-x 5 root root     4096 Sep  2 22:04 ..
-rwxrwxrwx 1 root root 76651552 Sep  2 22:37 3CXScheduledBackup.1.zip
-rwxrwxrwx 1 root root 76603185 Sep  2 22:37 3CXScheduledBackup.2.zip
-rwxrwxrwx 1 root root 76603185 Oct 13 03:59 3CXScheduledBackup.3.zip
-rwxrwxrwx 1 root root 76688210 Sep  2 22:37 3CXScheduledBackup.zip
-rwxrwxrwx 1 root root 13367798 Oct 13 03:59 3CXScheduledBackup.zip.tmp
-rwxrwxrwx 1 root root 77023500 Oct  4 16:44 Post-upgrade.zip
-rwxrwxrwx 1 root root 78692062 Oct  2 21:41 Pre-upgrade.zip

Creating a manual backup continues to work without any issue. The backup schedule has everything deselected except the license key to try and rule out any issues with voicemails etc. - the same options are selected for the manual backup.

Can anybody at 3CX provide any information on whether the scheduled backup runs under different permissions to the manual one?

It might just be that the scheduled backup tries to do something on the files which would usually work if it was talking to an actual file system as opposed to an SMB mount, and this isn't going to work, at which point I can give up and put the backups somewhere else. An option to write backups to S3-compatible storage would be a great feature to have, if we're putting ideas out.

 

[cobaltit]

Pretty sure you need to change the permissions so the phonesystem user can write to that location. If you su to the phonesystem user manual backups will likely fail.

 

[JohnS_3CX]

Hi @JonnyM

Please note that NAS/SMB/NFS is not supported. You need block-level write access rather than file system level access (ie. SATA, iSCSI,SAN) if you plan to use network storage otherwise your results will vary, and you will not be assured that the backup will be successful.

You can however backup locally, and then move it to your SMB if you wish to keep your current setup

 

[JonnyM]

Thanks John, it looked like it was after direct filesystem access towards the bottom of the error message after I looked at it closer. I'll backup locally and script a copy task to the SMB mount after the backup has completed.