just started running into this issue as of August 29th this year
Ask your webhost; those are Windows temp files. The server may not be deleting them correctly after a change at the host.
We’re actually the server host since we’re running this in-house for our company Intranet. Anything specific I should look into?
I’d look in the IIS server knowledge base at MS.
@cashadle
I am having the same problem. Have reached any solutions yet ?
Nothing yet, unfortunately. Can’t seem to figure out what would even be causing it.
@cashadle
Do you have SSO plugin installed on your intranet installation and anonymous access disabled ?
@diegorod
Yes, I’ve got AD Integration installed and anonymous access is disabled.
@cashadle
Alright we are getting somewhere. I have narrowed down the cause to one plugin – all-in-one-event-calendar – the plugin has a feature that checks for folder writability and even though it succeeds every time you perform the manual check (EVENTS -> SETTINGS -> ADVANCED Tab -> Check Again), it always reverts back to “Templates cache is not writable” when you keep checking that tab.
If you do have all-in-one-event-calendar plugin, check the folders along this path: \wp-content\plugins\all-in-one-event-calendar\cache
You will see that those temp-write-test files are being created along the way – but mostly at the beginning (wp-content) and end of the path (cache).
With that being said, I still am not sure what kind of configuration we need to prevent this plugin for doing this.
Looks like this is the case for me as well. We use the AI1EC for some general event information, but I might consider switching to another calendar plugin if this is what’s causing the issue.
Let me know if you figure out anything else, I’ll do the same.
I think I figured it out. From the reply to your thread over on their website, I decided to check the permissions on the /wp-content/ folder.
I noticed the server/users group did not have modify permissions. Since this group is just local to the server, I went and gave it modify permissions. After doing that, I loaded a couple pages on the Intranet (which usually would cause the temp-write-test files to be created every time).
Nothing. No new “temp-write-test” files were created. It seems like this was causing the issue as far as I can tell. It’s been about half an hour since I applied the new permissions, and I’ve yet to see any pop up. This is on our live site and I can see people hitting the Intranet every few minutes.
Thanks for the help!
@cashadle
Thanks for the heads up. Worked for me as well!
