Fixing Permission Errors | Hostinger Business Account *

/ SprUng, KEEPERS, CODING, CHEAT SHEETS, Follow up, SITE, WEBSITES, TOOLS / 7 minutes of reading

Fixing permissions errors on hostinger wordpress installations (business accounts)

"wordpress – Download failed. Destination directory for file streaming does not exist or is not writable. – I tink permissions are off on plugins folder"

Yep, that error usually means the WordPress plugins directory doesn’t have the right permissions or ownership set, so it can’t write downloaded files (like plugin updates or new installations). Here’s how you can fix it:

🔍 Step 1: Find your plugins folderUsually it’s:

/path/to/your/wordpress/wp-content/plugins/

If you’re unsure, go to the root of your WordPress install and run:

ls -la wp-content

Make sure plugins exists. 🔧 Step 2: Fix directory permissionsRun these from your WordPress root directory:

chmod -R 755 wp-content/plugins

That allows the web server to read and write (but not execute arbitrary scripts). 👤 Step 3: Fix ownership (important!)Let’s say your web server user is www-data (common on Ubuntu/Debian). Run:

chown -R www-data:www-data wp-content/plugins

Replace www-data with your actual web server user (apache, nginx, etc.), depending on your setup.

✅ Step 4: Test itGo back to the WordPress admin panel and try installing or updating a plugin again.

Let me know what kind of server you’re on (e.g., Ubuntu, AlmaLinux, Apache/NGINX, etc.) if you want me to tailor the commands to your setup. Good question — here’s a quick way to check who your web server is running as: 🧪 Option 1: Use

ps

to check running web server processesRun this in your terminal:

ps aux | egrep '(apache|httpd|nginx|php-fpm)' | grep -v root

This shows you the processes that are actually handling requests, and the first column is usually the user they’re running as.# Example output:

www-data  1234  0.0  ... /usr/sbin/apache2 -k start

So in this case, www-data is the user. 🧪 Option 2: Check with

whoami

from within a PHP file (for WordPress or LAMP stack)Create a file called whoami.php in your WordPress root:

<?php echo exec('whoami'); ?>

Then visit it in your browser: https://yourdomain.com/whoami.php It’ll output the web server user.

✅ Don’t forget to delete the file after checking — it can be a security risk if left up!

Let me know what OS or stack you’re running if you want me to walk through it specifically (Apache on Ubuntu, NGINX on AlmaLinux, etc).

Nice — that means no web server processes like apache, nginx, or php-fpm are currently running under a non-root user, which is a little unusual for a live WordPress site. Let’s dig deeper: 🔍 Step 1: Try checking again, but include

root

just to see what’s runningRun:

ps aux | grep -E '(apache|httpd|nginx|php-fpm)'

Let’s see if maybe they’re all running as root, or if something else shows up like daemon, nobody, or nginx. 🔍 Step 2: You can also check Apache directly (if you’re using it):

apachectl -V | grep -i user

You might see output like:

-D APACHE_RUN_USER=www-data

That means the web server runs as www-data. 🔍 Step 3: Check NGINX config (if you’re using NGINX)

grep -i '^user' /etc/nginx/nginx.conf

You might get:

user nginx;

Or:

Once we know the web server user, we can safely run the correct chown to give it access to the plugins folder. Want to paste the result here and I’ll confirm what command to use?

Alright — still no Apache, NGINX, or PHP-FPM processes showing. That’s interesting. Let’s try a different approach to find out what server software is actually running WordPress on your machine. ✅ Try this one instead:

user apache;

 


ps aux | grep -i php

or

ps aux | grep -i nginx

 

ps aux | grep -i apache

Paste the output here — we’re trying to find a line that shows something like:

www-data 1234 … php-fpm: pool www


nginx  1234  ... nginx: worker process

or



apache 1234  ... /usr/sbin/httpd

Once we spot the actual worker process, we’ll know exactly which user to grant write permissions to your wp-content/plugins folder. Also — do you know if this WordPress install is on:

  • Shared hosting?
  • A VPS you control?
  • Local machine?
  • Something like cPanel or Plesk?That might help narrow it down too.

Perfect — that tells us your web server is running LiteSpeed, specifically the lsphp process, which is how LiteSpeed handles PHP. And even better: it’s running as user YYYYYYYYY, which is your user on the server. So your web server doesn’t use a separate user like www-data — it’s all under your account. ✅ So here’s what to do next:From your WordPress root, run:

chmod -R 755 wp-content/plugins
chown -R YYYYYYYYY:YYYYYYYYY wp-content/plugins

This ensures your user (and therefore LiteSpeed) can write to the plugins folder. 🔁 Then try:– Installing or updating a plugin via the WordPress admin panel.

  • If it still fails, try the same fix on the full wp-content folder:
chmod -R 755 wp-content
chown -R YYYYYYYYY:YYYYYYYYY wp-content

Let me know how it goes or if it throws a new error after this.

Good question — but not quite. Let me break it down: 👤 The user

YYYYYYYYYThat’s your Linux system user — the one your hosting provider set up for you (probably on shared hosting). It’s the user running the LiteSpeed PHP processes (lsphp), which means WordPress runs as this user on the server side. 🌐 When you log in to the

WordPress frontendThat’s completely different — WordPress has its own system of users (stored in the database), like:

  • admin
  • editor
  • subscriber
  • etc.These users only exist inside WordPress, not on the server. So:
ActionUser Involved
File/folder permissionsYYYYYYYYYY (your server/Linux user)
WordPress login (wp-admin)WordPress database user (like admin)
FTP or terminal accessYYYYYYYYY again
Your WordPress admin user needs no special file permissions — it just makes requests that PHP handles, and PHP runs under your hosting user. 

Let me know if you want to double-check your WordPress user permissions too, like making sure your WP admin account has Administrator role.Perfect — that should fix it! 🎯 After that finishes running:

  1. Head back to your WordPress admin panel.
  2. Try installing or updating a plugin again.
  3. If it works — you’re good to go.
  4. If it still complains, let me know what the exact error is — it might be a temporary folder (wp-content/uploads or something else) needing the same fix.But 90% of the time, this takes care of it. Let me know how it goes — or if you want to do a quick security hardening pass after everything works.

Ah yep, classic shared hosting twist — looks like your system user doesn’t have a group with the same name (some providers do that, some don’t). No worries — let’s fix it easily. ✅ Step 1: Find your actual groupRun:


id

You’ll see something like this:


uid=YYYYY(YYYYYYYYY) gid=12345(somegroup) groups=12345(somegroup)

The part after gid= is your group name. ✅ Step 2: Use that in your

chown

commandLet’s say your group is nobody or users or whatever the id command showed — then run:

chown -R YYYYY:yourgroupname wp-content

🔁 Replace yourgroupname with the actual group (e.g., nobody, users, etc.).

Want to paste your id output here and I’ll give you the exact command?

Perfect — thanks! So your username is YYYYYYYYY and your group is o200948769. That means your corrected command is:


chown -R YYYYYY:XXXXXXX wp-content

Now everything should line up — ownership will match what your LiteSpeed PHP process expects, and WordPress should be able to write to wp-content/plugins.

Still no resolution

HOST ADVICE:

The error suggests that the destination directory for plugin updates is either missing or not writable. Since you’ve already reset folder permissions, try the following steps:
Check the wp-content folder permissions: Ensure the wp-content, plugins, and uploads folders have permissions set to 755, and files inside are 644. Double-check ownership to match your web server user.
Verify Disk Space: Ensure your hosting plan has sufficient disk space available for updates.
Temporary Folder Issue: Add the following line to your wp-config.php file to define a temporary folder:
define(‘WP_TEMP_DIR’, dirname(__FILE__) . ‘/wp-content/temp/’);
Create a temp folder inside wp-content and set its permissions to 755.



Let’s walk through it step-by-step to get this sorted for real:

✅ Step 1: Create a temp folder

From your WordPress root:

mkdir -p wp-content/temp
chmod 755 wp-content/temp

This gives WordPress a safe place to extract plugin files during installation.

✅ Step 2: AddWP_TEMP_DIR to wp-config.php**

 

Open wp-config.php in your WordPress root, and add this line near the bottom, just before the line that says /* That's all, stop editing! */:

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Make sure the path ends with a slash /, or WordPress may not find it properly.

 

✅ Step 3: Retry the plugin install/update

Go back to WordPress admin and try installing or updating the plugin again.

 

✅ Optional (but smart): Check disk space

Just in case this is a shared hosting space issue, run:

df -h .

That will show disk usage for your current directory. Look at the % used and make sure you’re not at or near 100%.

 

Scroll to Top