Permission denied

WordPress is showing this notice in the backend:

Your LogHero plugin cannot write to the “logs” folder (permission denied). Please set access rights properly or use the Redis log buffer with synchronous flush.

Nothing is being collected while this notice is up. The plugin buffers requests on disk before sending them, so if it cannot write, it cannot record anything — and it does not hold the data in memory in the meantime.

What the plugin needs to write

Everything lives in one folder inside the plugin directory:

wp-content/plugins/loghero/logs/

File	What it is
`buffer.loghero.io.txt`	The buffered requests waiting to be sent
`buffer.loghero.io.last-dump.timestamp`	When the buffer was last emptied
`settings.loghero.io.json`	A copy of your settings, readable without WordPress
`errors.loghero.io.*.txt`	The errors behind the admin notices

The folder ships with an .htaccess containing Deny from all, so nothing in it is reachable from the web even though it sits under the document root.

1. Give the folder back its write permission

The folder has to be writable by the user your web server runs as — often www-data, apache, nginx or your hosting account’s own user. It is almost always ownership that is wrong, not the mode.

Over SSH:

cd wp-content/plugins/loghero
chown -R www-data:www-data logs
chmod 755 logs

Over FTP or your host’s file manager, where you cannot change the owner: set the folder’s permissions to 755 and check that the FTP account and the web server are the same user. If they are not, 755 will not be enough and you need either 775 with a shared group or your host’s support.

The listing should read drwxr-xr-x and belong to the web server user. The plugin creates the files inside it with mode 0666 on its own.

Reload any admin page. The notice disappears as soon as the plugin can write.

2. If you cannot change permissions, buffer in Redis

Some hosts keep the plugin directory read-only by design, and on those the first step will never work. Switch the buffer to Redis instead, at Settings → LogHero → Advanced Setup:

Enter your Redis URL, for example tcp://127.0.0.1:6379.
Tick Disable Async Mode.
Save.

Both are required. The Redis URL moves the request buffer out of the folder, and synchronous mode removes the last thing that still needs it — the settings copy the asynchronous flush reads on its way in. With only one of the two set, the notice stays.

The cost of synchronous mode is that one request in roughly a thousand carries the round trip to the Log Hero API. See WordPress for what changes.

3. Check the folder still exists

A security plugin, a malware scan or a partial update can remove or rename the logs folder. Recreate it if it is gone:

mkdir -p wp-content/plugins/loghero/logs
chown www-data:www-data wp-content/plugins/loghero/logs
chmod 755 wp-content/plugins/loghero/logs
printf 'Deny from  all\n' > wp-content/plugins/loghero/logs/.htaccess

Reinstalling the plugin restores it too, and keeps your settings, which live in the WordPress options table rather than in that folder.

The same error from the PHP SDK

The PHP SDK throws PermissionDeniedException for the same reason, on the first request after deployment:

Permission denied! Cannot write to directory /var/lib/loghero

It checks the directory, not just the file, so a writable file in a read-only directory still fails. Give the directory to the user PHP runs as:

sudo install -d -o www-data -g www-data -m 755 /var/lib/loghero

Both the request hook and the flush endpoint need access to it, and they must point at the same path. If they run as different users — a queue worker and php-fpm, say — give the two a shared group and mode 775.

Still stuck?

Send the output of ls -la wp-content/plugins/loghero/ and the name of your host to support@log-hero.com.