Empty folders and files in wp-content/shield/

Hi,

Thanks for your question.

This is a temporary directory used by the plugin to store temporary data.

It is used by the scans and various other purposes in the plugin (only for certain features).

The data we write can oftentime be quite large and storing them in the DB is impractical. We also don’t access the data on every page load, they’re used primarily for file system scans. Some data we store in the DB, others to files, it just depends on their nature and use-cases.

When Shield looks for the directory, we simply use the PHP constant within WordPress: WP_CONTENT_DIR

We rely on this to be correctly declared and simply then build the directory off that, so in most cases it’ll be /wp-content/shield/.

Just please make sure that ‘shield’ directory is available for writing – that Shield is able to write to that directory.

Hope this helps.

Thanks,

Jelena

Hi Jelena,

thanks for your reply. Is it a normal behaviour to create a lot of folders but why are these folders not removed again? The folders and files have write-permissions by the webserver-user, who created it.

https://abload.de/img/sniprdj09.jpg

Thanks in advance.

• This reply was modified 2 years, 10 months ago by neralex.

I suspect there’s a filesystems permission issue here. The system tests whether it can write-read-delete both a folder and file. It’ll not leave the folder there unless the delete operation fails.

Also, given that it’s only started happening since the 24th (infered from the screenshot) perhaps something recently changed on the server to restrict that?

Ok, just tried it with a own php-file, which I placed in the root-folder of the affected wordpress-installation with the following code-lines:

<?php
$error_reporting = E_ALL;

$path = 'wp-content/shield';
$folder = 'dummy';
$filename = 'dummy.txt';

if (file_exists($path.'/'.$folder.'/'.$filename)) {
	unlink($path.'/'.$folder.'/'.$filename);
	rmdir($path.'/'.$folder);
} else {
	mkdir($path.'/'.$folder, 0777, true);
	file_put_contents($path.'/'.$folder.'/'.$filename, 'hello');
}

$dirs = array_filter(glob('*'), 'is_dir');
foreach ($dirs as $dir) {
	if (is_writable($dir)) {
		echo $dir.' is writable.<br>';
	} else {
		echo $dir.' is not writable.<br>';
	}
}
?>

The dummy-folder and also the dummy-file are created with the correct permissions and the delete operation works also as expected.

While checking the php-logs, I found entries like this:

Notice: Store directory could not be created: /themes, referer: https://domain.tld/wp-cron.php?doing_wp_cron=1643119329.3315219879150390625000

Notice: Store directory could not be created: /plugins, referer: https://domain.tld/wp-cron.php?doing_wp_cron=1643119464.1156771183013916015625

I’m pretty sure it’s not a file system permissions problem. All media files are saved and deleted correctly, as it also showed my test with the own PHP file. Maybe it is related to the error messages from the PHP logs.

Hi,

We’ve just released v14 and within that release we’ve added some reworking of the code to locate the directory used for snapshots in the hope it’ll alleviate whatever the issue is for your setup. Could you give it a go and see if it helps, please?

Thanks.

I just updated ShieldPRO and there is no debug.log anymore.

The error lines
[Build Asset] Notice: Store directory could not be created: /themes
[Build Asset] Notice: Store directory could not be created: /plugins
are gone.

Thx, great work.

• This reply was modified 2 years, 9 months ago by hdgram.

@paultgoodchild Thank you, it seems the issue is fixed. I will keep an eye on it on the next days.

Great to hear that, thanks for reporting back @neralex @hdgram