NGINX : failed (2: No such file or directory) in /etc/nginx/nginx.conf

My first configuration of an NGINX server left me high and dry for a while. Coming from an Apache back-ground (where everything is done for you), NGINX felt a little archaic at first.
There was not much help out there for this issue so I will fill in the gap.

The error (in this case) was due to my symbolic link not being created correctly in sites-enabled.
I will go into a little more detail.

nginx: [emerg] open() "/etc/nginx/sites-enabled/" failed (2: No such file or directory) in /etc/nginx/nginx.conf:62

This is the error (above) was being shown with any of the following commands :

  • Testing the configuration: sudo nginx -t
  • Starting or reloading the service:
    sudo service nginx restart
    sudo nginx -s reload
nginx: [emerg] open() "/etc/nginx/sites-enabled/" failed (2: No such file or directory) in /etc/nginx/nginx.conf:62

This message is a bit vague, but there is a subtle hint here. The last path is pointing to the file containing the problem and the appended number correlates to the specific line number in that file.

In my case, line 62 was:
include /etc/nginx/sites-enabled/*;

I know the syntax of the line is correct because I compared it with the default file included in the installation.

Similar to Apache, the sites-enabled directory is meant to store symbolic links of configuration files that are stored in sites-available. Unlike Apache, however, the symbolic links need to be manually created by the admin, as apposed to an Apache command that automatically creates and removes the links when asked.

Navigating to /etc/nginx/sites-enabled, I checked the symbolic link using the following command

sudo ls -la lrwxrwxrwx 1 root root   32 Jul 19 20:16 -> sites-available/

I previously created this link whilst in the /etc/nginx folder using the following command:
sudo ln -s sites-available/ sites-enabled/

Looking back at the ls output, the local filename is correct, however the file path that it is pointing to isn’t.
The correct path should be:

The solution was to simply create a new symbolic link to the configuration file, but using absolute paths instead of being lazy.

sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

After this, NGINX complained no more and after a silent reload, instantly served my webpage on the World Wide Web. Nice.

Yes, this was complete user-error spurred from my lack of knowledge of symbolic links, however this is no longer a problem and I can get back to development.

Hopefully this will save someone else loads of time!

Linux vs Windows: Python Virtualenv

Although Virtualenv is available on both Linux and Windows, there are some differences that you may find useful to understand.

Is there a difference to creating virtualenvs?

No, creating virtualenvs in Windows and Linux is exactly the same.

Can I use the same venv folder on both systems?

No. You will need to create 2 separate virtual environments. I suggest creating folders named winvenv and linvenv to tell them apart. You will have access to the same packages through pip, although you will need to use pip freeze if you wanted to replicate the packages exactly.

Do I activate the venvs in the same way?

No, but you CAN activate, and the differences are subtle. After creating the virtualenv, follow these steps:


\winvenv\Scripts> activate

Navigate to Scripts within the venv root. Type activate to use your venv in the current prompt


$ source linvenv/bin/activate

In the terminal, type source followed by the path to /bin/activate within the viretualenv folder

uhex – a CLi hex editor

A quick and easy to use CLi script to transform hex values into different data types.

Current known limitations:

  • Hex order : will only convert from Big-Endian hex orders
  • Hex to int : will only convert hex to unsigned integers

Known Issues:

  • Hex to float not yet fully working

The script is available from github :

github : uhex

WordPress XMLRPC.php is now working!

I really like the additional features provided by the Jetpack plugin, and after the recent migration, it stopped working. I checked over permissions, .htaccess, WP configurations and even cross referenced some major server configs to try and figure it out.

I remembered that I had this issue before and needed to install another module somewhere, but unfortunately couldn’t quite put my finger on it. Looking at apache2 error logs, after several tries at linking to, and XML error showed up. A quick Google of this informed me of a PHP XML module.

The PHP module is needed to produce and receive the XML through the RPC API.

Since I’m using PHP 7.0, all I had to do was issue this command:

sudo apt install php7.0-xml

If your running a LAMP stack, you can change the version to your current PHP version, or simply:

sudo apt install php-xml

could work too (although some people have had issues with this “generic” module)

Restart Apache2 and you should be good to blog from anywhere!


I was awoken today with a rather rude message indeed. An email from Jetpack plugin notifying me that the website was down. I often get this message at the most awkward of times, mainly whilst unable to log in to the server.

Opening up the site shows me an alarming message “Unable to contact database”…. the worst kind of messages. Databases have never been my strong point… I find them terribly complicated and I tend to just leave them alone as much as I can.  Now what? Annoyingly MYSQL seems to quickly zip up any MYSQL error log files, often leaving the latest error log almost completely empty. Another annoyance.

Trawling through the logs, I can see MYSQL has shut down, restarted, shut down, restarted, until it finally gave up. Quickly found the error…

innodb is trying to pass over 130MB of indexed(?) files to the allocated defaulted 128MB buffer size pool. After a bit of tinkering and increasing the size, the site not only has greatly improved response time, but it should cure the site from going down regularly.

It’s not fixed until the fat server sings…

It’s early days but I’m confident the issue is resolved. I will monitor the situation to hopefully find 30 WHOLE DAYS of uptime. Here’s hoping.
( that is not an invitation btw 🙂 )