You set up a LEMP stack on Ubuntu 20.04, followed the tutorial, and now things are… not quite right.
PHP doesn’t seem to work properly.
Or WordPress installs fine, but you can’t upload files larger than 2MB.
And every guide you find suggests editing some random php.ini or .htaccess and ends up breaking things.
Let’s clean this up step by step.
I’ll stay within what’s implied by the source: Ubuntu 20.04 with Nginx, MySQL 8.0, PHP 7.4, and a basic WordPress install on a LEMP stack.
1. Who This Is For (And What We’re Fixing)
This article is for you if:
- You followed a LEMP-on-Ubuntu-20.04 tutorial.
- You symlinked your Nginx site config with:
sudo ln -s /etc/nginx/sites-available/your_domain /etc/nginx/sites-enabled/- You removed the default Nginx config with:
sudo unlink /etc/nginx/sites-enabled/default- PHP “installation was unsuccessful” or PHP pages don’t render.
- WordPress works but you’re stuck with tiny upload limits (like 2MB) and don’t know where to change PHP limits.
We’ll walk through:
- Verifying PHP-FPM is installed and running.
- Basic Nginx + PHP checks.
- Where to adjust PHP limits (upload size, memory) in a safe, predictable way.
- What not to touch (like
.htaccesson Nginx).
No fancy tricks, just a clear, repeatable path.
2. Check If PHP Is Actually Installed and Running
If PHP “installation was unsuccessful”, the first job is to confirm whether PHP-FPM is installed at all.
On Ubuntu 20.04, the defaults mentioned in the source are:
- MySQL: 8.0
- PHP: 7.4
So PHP-FPM is usually named like php7.4-fpm.
Step 1: Check if php-fpm is installed
Run:
php -v
If PHP is installed, you’ll see a PHP version output (e.g., PHP 7.4.x).
If you get “command not found” or similar, PHP is not installed.
Step 2: Check PHP-FPM service
Run:
sudo systemctl status php7.4-fpm
Look for:
Active: active (running)→ PHP-FPM is running.- If it says
inactive,failed, or “Unit not found”, PHP-FPM is missing or broken.
If PHP-FPM is missing, follow the same tutorial steps you used originally, but pay attention to the exact package name used there (on Ubuntu 20.04, the default PHP is 7.4 and package names typically include that version).
The key point: PHP must be installed and PHP-FPM must be running before Nginx can serve any PHP pages.
3. Confirm Nginx Is Talking To PHP-FPM
Even if PHP is installed, your Nginx site config might not be wired correctly.
Since you already did:
sudo ln -s /etc/nginx/sites-available/your_domain /etc/nginx/sites-enabled/
sudo unlink /etc/nginx/sites-enabled/default
…you need to make sure your_domain has a PHP block pointing at PHP-FPM.
Step 1: Open your site config
sudo nano /etc/nginx/sites-available/your_domain
Look for a location ~ \.php$ { ... } block.
There should be something like:
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}
Two important bits:
include snippets/fastcgi-php.conf;→ handles standard FastCGI params.fastcgi_pass unix:/run/php/php7.4-fpm.sock;→ sends PHP requests to PHP-FPM.
If that block is missing or commented out, PHP files won’t be processed.
Step 2: Test Nginx config safely
Any time you change Nginx config, test before reload:
sudo nginx -t
- If it says
syntax is okandtest is successful, then reload:
bash
sudo systemctl reload nginx
If the test fails, undo or fix the last change before trying again.
This is your safety net against taking the whole site down.
4. Fixing WordPress Upload Limit (2MB Issue)
You installed WordPress, it works, but uploads larger than 2MB fail.
You then went on a config treasure hunt: nginx.conf, php.conf, random php.ini files, .htaccess… and some changes even broke the site.
Let’s simplify.
From what’s described in the source, this stack is:
- Nginx (LEMP)
- PHP-FPM (PHP 7.4 on Ubuntu 20.04)
- WordPress
On this setup you do not use .htaccess for PHP limits because .htaccess is an Apache thing.
Nginx ignores .htaccess entirely.
So you can skip .htaccess for upload size and memory limit.
Where to change limits (short version):
- Upload size limit → PHP config (e.g.,
php.ini). - Memory limit → PHP config (same place).
- Sometimes Nginx may also have its own limit (
client_max_body_size), but your main control is PHP.
Step 1: Find the active PHP config file
On a PHP-FPM install, the main PHP configuration is usually in a directory related to the PHP version.
The exact path will depend on how PHP was installed in your case, but your tutorial likely referenced a php.ini under the PHP 7.4 config tree.
Look for a php.ini under the PHP 7.4 folder used in the tutorial you followed.
For example, your tutorial may have told you something like “edit the FPM php.ini” in its PHP section.
Use that same file again.
Open it with:
sudo nano /path/to/that/php.ini
(Use the exact path given in your tutorial for Ubuntu 20.04; stay consistent with it.)
Step 2: Update upload and memory settings
Inside that php.ini, search for these lines (use CTRL+W in nano):
upload_max_filesizepost_max_sizememory_limit
Set them to values that make sense for you. For example:
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
Quick explanation:
upload_max_filesize: Max size of a single uploaded file.post_max_size: Max size of the entire POST body (must be >= upload_max_filesize).memory_limit: Memory PHP is allowed to use per script; WordPress can complain if too low.
Save and exit.
Step 3: Restart PHP-FPM and reload Nginx
After changing php.ini, restart PHP-FPM so the changes take effect.
Use the same service name you checked earlier.
sudo systemctl restart php7.4-fpm
sudo systemctl reload nginx
Now test uploading again in WordPress (Media → Add New) with a file bigger than 2MB.
If it still fails due to size, you may have an Nginx-level limit in place.
Step 4: Check Nginx for body size limit (optional)
Open your main Nginx config or site config used in your tutorial.
Look for:
client_max_body_size
If present and too small (like 1M or 2M), raise it to match your PHP setting, for example:
client_max_body_size 64M;
Then test and reload Nginx:
sudo nginx -t
sudo systemctl reload nginx
Now your upload limit should match your new settings.
5. Why Editing Random Files Breaks Things
From the comments in the source, I can see the usual confusion:
“Where do I need to make adjustments?
nginx.conf,php.conf,php.iniin various directories or.htaccess? or multiple places? some suggestions online seems to break the website.”
This happens because:
- Ubuntu 20.04 uses different default PHP/MySQL versions than older guides (PHP 7.4, MySQL 8.0).
- PHP config can live in several different config files, and not all of them are active for PHP-FPM.
.htaccessdoesn’t apply to Nginx.
To stay sane:
- Stay within the tutorial’s paths.
- Use the same
php.inithe tutorial used for Ubuntu 20.04. -
Don’t mix configs from Apache-based WordPress guides if you’re on pure Nginx.
-
Change one thing at a time.
- Adjust PHP limits in
php.ini. -
If upload size still fails, then check for
client_max_body_sizein Nginx. -
Always test before reload.
sudo nginx -tbeforesudo systemctl reload nginx.
This keeps your risk low.
6. Quick Checklist: PHP Not Working vs Upload Limit
If PHP installation seems broken:
- [ ]
php -vshows a PHP version. - [ ]
sudo systemctl status php7.4-fpmis active and running. - [ ] Your Nginx site config has a
location ~ \.php$block pointing to PHP-FPM. - [ ]
sudo nginx -tpasses, then Nginx is reloaded.
If WordPress uploads are stuck at 2MB:
- [ ] You do not rely on
.htaccess(this is Nginx/LEMP, not Apache). - [ ] You edited the proper
php.iniused in your tutorial. - [ ]
upload_max_filesize,post_max_size, andmemory_limitare raised. - [ ] PHP-FPM was restarted after editing
php.ini. - [ ] Nginx config doesn’t force a smaller
client_max_body_size.
If you want a more automated route for WordPress on LEMP with tuned settings, one of the comments in the source mentions using a script that configures PHP, Nginx, and MySQL automatically for WordPress on Ubuntu 20.04-style stacks.
That can be an option if you’d rather avoid manual tuning every time.
But even then, understanding the basics above will save you when something acts weird.
Need more help? Check the latest CrushEdge posts.
No Comments