If you’re setting up a LEMP stack on Ubuntu 20.04 and you:

• Followed a guide exactly, but PHP “didn’t install” or doesn’t run
• Have WordPress running, but uploads are stuck at 2MB
• Aren’t sure whether to edit nginx.conf, php.ini, php.conf, or .htaccess

…you’re in the right place.

This is for anyone running Ubuntu 20.04 with Nginx, MySQL 8.0, and PHP 7.4, trying to host WordPress or basic PHP sites and getting stuck on the last (annoying) 10%.

Let’s walk through what to check, what to edit, and how to not break things.

1. Before You Touch Anything: Know Your Stack

On Ubuntu 20.04, the defaults are:

• MySQL 8.0 (not 5.7)
• PHP 7.4 (not 7.0 / 7.2)

So if a tutorial talks about php7.2-fpm or older packages, the commands won’t match.

Quick sanity check (don’t change anything yet):

php -v

php-fpm7.4 -v  # This may or may not exist depending on how PHP was installed

mysql --version

If php -v doesn’t show PHP 7.4, then PHP isn’t installed correctly, or the CLI binary isn’t present. That’s the first problem to fix.

Also, remember: you’re using Nginx, not Apache. That means:

• .htaccess files do nothing
• All the WordPress .htaccess tricks from random blogs will not help you

Stick to Nginx and PHP-FPM configs.

2. Nginx Site Symlinks: Avoid a 404 or Blank Page

A lot of people follow a LEMP guide and hit this step:

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

sudo unlink /etc/nginx/sites-enabled/default

This is fine, as long as:

• /etc/nginx/sites-available/your_domain actually exists
• The filename is correct (no typos)
• The config inside that file is valid

Quick checks:

ls -l /etc/nginx/sites-available/
ls -l /etc/nginx/sites-enabled/

sudo nginx -t

What to look for:

• Does your_domain show up in both sites-available and sites-enabled (symlink)?
• Does sudo nginx -t say syntax is ok and test is successful?

If the test fails:

1. Read the error line and file path.
2. Fix the syntax (often a missing ; or brace).
3. Test again: sudo nginx -t.
4. Only then reload: sudo systemctl reload nginx.

If you remove the default site but your custom site config is broken, you can end up with Nginx running but serving nothing useful. Always test before reloading.

3. PHP “Installation Failed” vs PHP Just Not Used

Sometimes PHP is actually installed, but Nginx isn’t passing .php files to PHP-FPM, so it feels like PHP is missing.

You might see:

• Download dialog for index.php
• Raw PHP code showing in the browser
• 502 Bad Gateway for PHP pages

These are usually config issues, not missing PHP.

Key things to confirm in your Nginx server block (/etc/nginx/sites-available/your_domain):

1. There’s a location block for PHP, something like:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}

1. The PHP-FPM socket path matches what’s really running.

Check PHP-FPM service names:

systemctl status php7.4-fpm

If it’s active (running), see what socket file is configured inside /etc/php/7.4/fpm/pool.d/www.conf (look for listen = ...). Your fastcgi_pass in Nginx must match that value.

After any config change:

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl restart php7.4-fpm

If the guide you followed used a different PHP version (like php7.2-fpm), that alone can break PHP on Ubuntu 20.04.

4. WordPress Upload Stuck at 2MB: What Actually Controls It

Okay, your basic WordPress works but you can’t upload anything over 2MB.

This is not a WordPress bug. It’s usually a combination of:

• upload_max_filesize (PHP)
• post_max_size (PHP)
• Nginx client_max_body_size

Again, .htaccess is irrelevant here because Nginx doesn’t use it.

On a typical Ubuntu 20.04 + PHP 7.4 install, the main PHP config file is something like:

/etc/php/7.4/fpm/php.ini

You may also have a separate /etc/php/7.4/cli/php.ini, but for web requests, fpm/php.ini is the important one.

5. Safely Increasing PHP Upload Limits

Before editing anything, note:

• A typo in php.ini can break PHP-FPM
• Always restart PHP-FPM after changes

Steps:

1. Open the FPM php.ini:

sudo nano /etc/php/7.4/fpm/php.ini

1. Find and update these values (use Ctrl+W in nano to search):

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M

Pick values that make sense for your site. If you only need 10MB uploads, set them to 10M or 16M.

1. Save and restart PHP-FPM:

sudo systemctl restart php7.4-fpm

If you mess up and PHP-FPM won’t restart, check for errors:

sudo systemctl status php7.4-fpm

Fix the line it complains about, then restart again.

6. Matching Nginx Body Size With PHP Limits

Even if PHP limits are higher, Nginx itself can block larger uploads.

The directive to look for is:

client_max_body_size

It can be set in:

• /etc/nginx/nginx.conf (global)
• Or inside your server block in /etc/nginx/sites-available/your_domain

To keep it simple, you can set it inside your server block so it only affects that site.

Example in your server block:

server {
    server_name your_domain;
    root /var/www/your_domain;

    client_max_body_size 64M;

    # ...rest of your config
}

Make sure this value is >= your upload_max_filesize in PHP.

Then test and reload Nginx:

sudo nginx -t
sudo systemctl reload nginx

After that, go to WordPress → Media → Add New and check the “Maximum upload file size” value. It should reflect your new PHP limits.

7. Why `.htaccess` Won’t Help (And Can Even Confuse You)

A lot of guides say:

php_value upload_max_filesize 64M
php_value post_max_size 64M

…inside .htaccess.

That’s for Apache, not Nginx.

On a LEMP stack:

• .htaccess files are ignored
• PHP values must be changed in php.ini (or per-pool/per-site overrides)
• Nginx behavior is controlled only by Nginx config files

So if you’ve been editing .htaccess and seeing nothing change, that’s why.

8. Basic Safety Tips When Tweaking LEMP Configs

A few habits that save headaches:

1. Backup configs before editing

sudo cp /etc/php/7.4/fpm/php.ini /etc/php/7.4/fpm/php.ini.bak
sudo cp /etc/nginx/sites-available/your_domain /etc/nginx/sites-available/your_domain.bak

If something breaks, you can roll back quickly.

1. Always test Nginx before reload

sudo nginx -t && sudo systemctl reload nginx

If the test fails, it won’t reload and won’t take down your current working config.

1. Restart PHP-FPM after PHP changes

Changing php.ini does nothing until you restart PHP-FPM.

sudo systemctl restart php7.4-fpm

1. Make one change at a time

Don’t edit Nginx, PHP, and WordPress settings all at once. Change, test, then move on.

9. When PHP Really Didn’t Install Correctly

If php -v shows nothing useful and php7.4-fpm service doesn’t exist, then the installation itself is the problem.

Double-check the package names your tutorial used. If they referenced older PHP versions (like php7.2-fpm), they won’t install on straight Ubuntu 20.04 without third-party PPAs.

The fix in that case is to:

• Remove any half-installed PHP packages
• Install the correct PHP 7.4 packages

But since we’re sticking strictly to the behavior described in the source and comments, the main takeaways are:

• On Ubuntu 20.04, expect PHP 7.4 and MySQL 8.0
• Use version-correct service and socket names in Nginx

If your guide uses different version numbers, adjust them to 7.4/8.0 on this OS.

10. Quick Recap

• On Ubuntu 20.04, the defaults are MySQL 8.0 and PHP 7.4, not older versions.
• If PHP “fails,” often the real issue is wrong PHP-FPM version/socket in Nginx.
• Don’t touch .htaccess on Nginx; it does nothing there.
• Increase upload size by editing upload_max_filesize, post_max_size, and memory_limit in /etc/php/7.4/fpm/php.ini, then restarting PHP-FPM.
• Match or exceed those values in Nginx with client_max_body_size, then test and reload.
• Always backup config files and test Nginx before reloading to avoid downtime.

Need more help? Check the latest CrushEdge posts.