Fix SFTP “Permission Denied” on the New WordPress by Lightsail Blueprint (FileZilla, WinSCP, Any Client)

Verified July 2026 on the new “WordPress by Lightsail” blueprint. If your instance uses the older Bitnami blueprint, this guide is not for you — see the note at the end.

You spin up a fresh WordPress instance on AWS Lightsail, connect with FileZilla, try to upload a file into /var/www/html — and get permission denied. So you search for a fix, and every tutorial tells you to run sudo chown -R bitnami:daemon /opt/bitnami/wordpress.

There’s just one problem: there is no bitnami user on your server, and there’s no /opt/bitnami directory either.

That’s because in early 2026, AWS launched a brand-new WordPress by Lightsail blueprint that doesn’t use Bitnami packaging at all. Almost every guide on the internet still targets the old Bitnami stack, so the standard advice doesn’t just fail — the paths and usernames don’t even exist. This post covers the correct fix for the new blueprint: full SFTP read/write access for you, with zero loss of write access for WordPress itself (plugin updates, media uploads, and core updates all keep working).

One more thing before we start: although FileZilla is the example throughout — it’s the client AWS’s own tutorial uses — nothing about this problem is FileZilla-specific. The denial comes from Linux file permissions on the server, not from your client, so the fix below is identical for WinSCP, Cyberduck, Transmit, or plain sftp/scp from a terminal.

How the new blueprint differs from Bitnami

The new blueprint is a different animal from the old one:

Two of those are worth pausing on. First, your SFTP username is admin, not bitnami or ubuntu. Second, wp-config.php deliberately lives outside the web root at /var/www/wp-config.php, locked down to 440 permissions — a nice security touch, but confusing if you go looking for it inside html/.

Why you get permission denied (FileZilla, WinSCP, or any SFTP client)

SSH in and look at the web root:

ls -la /var/www/html

You’ll see something like this:

drwxr-sr-x  5 www-data www-data  4096 Jul  1 15:42 .
drwxrwsr-x  3 admin    www-data  4096 Jul  1 16:05 ..
-rw-r--r--  1 www-data www-data   405 Jul  1 09:28 index.php
drwxr-sr-x  9 www-data www-data  4096 Jun 11 15:39 wp-admin
drwxr-sr-x 13 www-data www-data  4096 Jul  1 10:46 wp-content
drwxr-sr-x 35 www-data www-data 16384 Jun 11 15:39 wp-includes
...

Everything is owned by www-data:www-data — the web server / PHP-FPM user. Directories are 2755 and files are 644, which means the group can read but not write. Your admin user isn’t the owner and (out of the box) isn’t in the www-data group, so FileZilla can browse everything and change nothing.

But notice the s in drwxr-sr-x. That’s the setgid bit, and AWS pre-set it on every directory in the tree. It means any new file created inside automatically inherits the www-data group. In other words, AWS already built half of a shared-group permission model into this image — they just didn’t flip the group-write bit or add admin to the group. We only need to finish what they started.

That’s also why this fix is safe: we’re not fighting the blueprint’s design, we’re completing it.

The fix: three commands

SSH into your instance (Lightsail’s browser terminal works fine) and run:

# 1. Add your SSH user to the web server's group
sudo usermod -aG www-data admin

# 2. Give the group write access — dirs get 2775 (preserving setgid)
sudo find /var/www/html -type d -exec chmod 2775 {} \;

# 3. Files get 664
sudo find /var/www/html -type f -exec chmod 664 {} \;

Copy-paste caution: keep the -a in usermod -aG. Without it, -G replaces your entire group list — which strips admin out of the sudo group and locks you out of root. Classic footgun.

A few reassuring details:

• Ownership doesn’t change. WordPress (www-data) still owns every file, so dashboard plugin updates, media uploads, and core updates work exactly as before. We only added a group write bit.
• find -type d and -type f don’t follow symlinks, so the blueprint’s phpmyadmin -> /usr/share/phpmyadmin link is untouched.
• wp-config.php isn’t in this tree (it’s at /var/www/), so its hardened 440 permissions stay intact.

Now the critical step everyone skips: log out and reconnect. Group membership only loads at login. Quit FileZilla completely (it holds the SSH session open) and close any SSH terminals, then reconnect.

Verify it worked

After reconnecting, confirm your session picked up the group:

id
# should now include: 33(www-data)

Then a quick write test — no sudo anywhere:

touch /var/www/html/wp-content/permtest.txt
ls -la /var/www/html/wp-content/permtest.txt
# -rw-r--r-- 1 admin www-data 0 Jul  7 04:21 permtest.txt
rm /var/www/html/wp-content/permtest.txt

If touch succeeds, the group model works. Note the file came out as admin www-data — that’s the setgid inheritance doing its job.

In FileZilla, upload a small file into wp-content/, rename it, delete it, and overwrite an existing file. All four should now work.

On the WordPress side, do three quick checks in wp-admin:

1. Media Library — upload an image (tests PHP writes to uploads/)
2. Plugins — update or install something; if WordPress asks for FTP credentials, something’s wrong (it shouldn’t)
3. Tools → Site Health → Info → Filesystem Permissions — everything should read “Writable”

The umask gotcha (don’t skip this)

Look again at that test file: -rw-r--r-- — that’s 644, not 664. Files you create over SSH or SFTP land with the group write bit missing, because the default umask is 022.

Practical consequence: everything you upload via FileZilla is readable but not writable by WordPress. Upload a plugin manually today, and six months from now its auto-update fails with “could not copy file.” Your access is fine either way (directory permissions cover create/rename/delete, and you own your own files) — it’s WordPress that slowly loses write access to your uploads.

The clean fix is a one-line change to the SFTP server’s umask. Edit the SSH daemon config:

sudo nano /etc/ssh/sshd_config

Find this line:

Subsystem sftp /usr/lib/openssh/sftp-server

Change it to:

Subsystem sftp /usr/lib/openssh/sftp-server -u 0002

Then validate the config before restarting — a typo in sshd_config is one of the few ways to genuinely lock yourself out:

sudo sshd -t     # no output = config is valid
sudo systemctl restart ssh

Restarting ssh won’t drop your current session, and Lightsail’s browser SSH is always there as a safety net — but keep your existing terminal open until you’ve confirmed a fresh connection works.

If you also edit files from the shell (nano, wp-cli, git), fix the shell side too:

echo "umask 002" >> ~/.bashrc

Both changes apply to new sessions only, so reconnect once more. Then re-run the FileZilla upload test — the file should now show rw-rw-r-- (664). That’s your confirmation that WordPress keeps write access to everything you upload from now on.

Optional: make WordPress return the favor

There’s a mirror-image issue in the other direction. When WordPress itself creates files — core updates, plugin installs from the dashboard — it chmods them to 644 by default. Over time you accumulate files you can delete or replace via FileZilla (directory permissions cover that) but not edit in place.

The fix lives in wp-config.php — which, remember, is at /var/www/wp-config.php on this blueprint:

sudo nano /var/www/wp-config.php

(sudo bypasses the file’s 440 permissions — no need to chmod it first.) Add near the other defines:

define('FS_CHMOD_FILE', 0664);
define('FS_CHMOD_DIR', 02775);

With that, WordPress creates files group-writable too, and neither side ever locks the other out again. If you skip this, the fallback is simply re-running the two find ... chmod commands whenever you hit a stubborn file.

What NOT to do

Two “fixes” you’ll see in older tutorials that you should avoid on this blueprint:

Don’t chown -R admin the tree. Taking ownership away from www-data breaks WordPress’s ability to self-update and write uploads — the exact thing we’re trying to preserve. The whole point of the group model is that nobody has to give anything up.

Don’t chmod -R 777. It “works” the way removing your front door “fixes” losing your keys. Group write gives you identical day-to-day convenience while keeping every other process on the box (and any compromised PHP script) from writing to your files with world permissions.

One optional hardening note: the blanket 664 also applies to .htpasswd (which gates phpMyAdmin on this image). If you’d rather that hash not be world-readable:

sudo chmod 660 /var/www/html/.htpasswd

You and WordPress keep access through owner/group; other users can’t read it.

Quick reference

The complete fix, start to finish:

# Shared group access
sudo usermod -aG www-data admin
sudo find /var/www/html -type d -exec chmod 2775 {} \;
sudo find /var/www/html -type f -exec chmod 664 {} \;

# SFTP umask (edit /etc/ssh/sshd_config):
#   Subsystem sftp /usr/lib/openssh/sftp-server -u 0002
sudo sshd -t && sudo systemctl restart ssh

# Shell umask (optional — only if you create/edit files from the shell)
echo "umask 002" >> ~/.bashrc

# Optional: WordPress side (add to /var/www/wp-config.php)
#   define('FS_CHMOD_FILE', 0664);
#   define('FS_CHMOD_DIR', 02775);

# Then: reconnect FileZilla + SSH (group/umask apply at login only)

FAQ

What’s the SSH/SFTP username for the new WordPress by Lightsail blueprint?

admin — the blueprint is Debian-based. (bitnami is the old blueprint; ubuntu is for plain Ubuntu instances.)

Where is wp-config.php on the new blueprint?

/var/www/wp-config.php — one level above the web root, with 440 permissions. Edit it with sudo nano.

Does this guide work on Bitnami Lightsail instances?

No. Bitnami uses different users (bitnami/daemon) and paths (/opt/bitnami/wordpress). If whoami over SSH returns bitnami, you’re on the old blueprint and need the Bitnami-specific fix instead.

Does this also happen with WinSCP, Cyberduck, or other SFTP clients?

Yes — the “permission denied” is enforced by Linux on the server, so every SFTP client sees the exact same error, and so do scp, rsync, and shell commands run as admin. Fix it once on the server and every client works. (Lightsail instances don’t run a plain FTP server at all, by the way — file transfer is SFTP over SSH on port 22, which is exactly why the umask fix lives in sshd_config.)

Will this break WordPress updates or uploads?

No — that’s the point of this approach. www-data keeps ownership of everything; you’re only joining its group. All three verification checks (media upload, plugin update, Site Health) should pass unchanged.

Ran into a different permissions issue on the new blueprint? Drop it in the comments — this stack is new enough that the community is still mapping its quirks.