403 Forbidden NGINX - Web Management Interface Inaccessible

[Benjamin Williams]

I posted about this error a few months ago and didn't get much traction on it. I run several 3CX instances, most of the them Linux based w/a few of them running on Windows.
I am experiencing a problem w/one of the Windows 3CX instances - in short, when I attempt to access the web interface using a browser, (doesn't' matter which browser is used) the following web error message is thrown.



I've restarted all 3CX services, I've rebooted the server, nothing seems to work. (I've spent a lot of time troubleshooting this problem and I'm assuming that it might just have something to do with some type of underlying data corruption w/NGINX..) - Aside from not being able to get to the 3CX management-console, everything else seems to work; that is, backups are still working, alert notifications are still coming through, phone calls <inbound & outbound> are still working, all services are up and running.

At this point, I am thinking about spinning up a Linux based 3CX instance and performing a restore of the Windows config. I wanted to confirm a few things prior to moving forward w/these changes.

- The 3CX configuration taken from a Windows 3CX instance can be restored on a Linux 3CX instance, correct (?)

 

[SweetAction]

At this point, I am thinking about spinning up a Linux based 3CX instance and performing a restore of the Windows config. I wanted to confirm a few things prior to moving forward w/these changes.

- The 3CX configuration taken from a Windows 3CX instance can be restored on a Linux 3CX instance, correct (?)

Correct.

If you feel like tinkering, the NGINX logs should tell us more.

You'll have to edit the conf, enable the log, restart nginx, reproduce the issue.
Off the top of my head it's here:
bin -> nginx -> conf -> nginx.conf
and then look for
access_log off;
and change it to
access_log c:\temp\log.txt; or similar.

 

[Benjamin Williams]

Thank you for the response - I have enabled logging within NGINX - I will collect those logs later this morning/afternoon and post back my findings.

 

[Benjamin Williams]

Okay - so I think I found out the problem. For whatever reason, the folder 'wwwroot' located within this directory (C:\ProgramData\3CX\Data\Http) only has about 30 files in it. (????) - I compared that against another customer of ours (who also runs a Windows version of 3CX) and their wwwroot directory has over 3,300+ files.

The server in question does not have any A/V installed on it. I am not sure what would have caused all of these files to be deleted/removed?

A couple of questions:

1) I have a backup of the server but I will have to go back around 3 months to restore the wwwroot directory. The problem is that the backup is a VHD file that is over ~55GB in size - this is going to take a very long time to download from the cloud and restore the directory.

2) I assume copying the wwwroot from another Windows 3CX instance would be a no-no (?) The directory from the 'working 3CX instance' is roughly 35MB's in size. So, the process of restoring would be much, much faster.

 

[SweetAction]

I mean, the fastest safest way to resolve this is to take a backup, reinstall, restore backup. I haven't looked at Windows install in some time (we're 100% linux deployments these days), but I assume the provisioning subdir is in wwwroot, which means there are customer specific files there (phone specific xmls for example).

You can grab a backup via command line if need be.

Just curious, did you discover this based on the nginx logs or just poking around.

 

[Benjamin Williams]

I did not discover it from the NGINX logs; TBH, the only bit of log info that I received when attempting to access the Web Management console from the NGINX logs was this...

XX.XX.XX.XX - - [13/Oct/2022:15:00:48 -0700] "GET / HTTP/2.0" 403 548 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36"

At this point, I'll go ahead and schedule a maintenance window that I can run a backup of the PBX (via the command line) and reinstall/restore.

Thanks for all your help, I appreciate it!

 

[SweetAction]

The Nginx 403 Forbidden error is a status code that arises when a client attempts to access a section of the web server for which they lack the necessary permissions. When Nginx encounters a request to access a directory, its default behavior is to attempt indexing the directory and presenting the list of contained files to the browser or client. Nevertheless, since directory indexing is disabled by default, this action results in the 403 Forbidden error being displayed instead.

Incorrect Index File

The try_files tries the literal path you specify in relation to the defined root directive and sets the internal file pointer. If you have directory indexing off, and is having this problem, it's probably because the try_files you are using has a directory option:

location / {
try_files $uri $uri/ /index.html index.php;
}

to
location / {
try_files $uri /index.html index.php;
}

Incorrectly set permissions

This error can also result from files and directories having incorrectly set permissions. In order to resolve this , change the directories permission to 755 and the file permissions to 644 . Make sure that the user running the Nginx process owns the files. For example, set user to www-data:

sudo chown -R www-data:www-data *

Finally, set the directory and file permissions as:

sudo chmod 755 {dir}
sudo chmod 644 {files}

ChatGPT, is that you?