Symfony error writing to cache

[gsmaclean]

Support Request Template
What version of phpBB are you using? phpBB 3.2.0
What is your board's URL? http://goldwingdocs.com
Who do you host your board with? Self
How did you install your board? I used the download package from phpBB.com
What is the most recent action performed on your board? Update from a previous version of phpBB3
Is registration required to reproduce this issue? No
Do you have any MODs installed? No
Do you have any extensions installed? No
What version of phpBB3 did you update from? phpBB 3.1.9
What styles do you currently have installed? ProSilver
What language(s) is your board currently using? English
Which database type/version are you using? MS SQL Server
What is your level of experience? Experienced with PHP and phpBB
What actions did you take (updating your board; installing a MOD, style or extension; etc.) prior to this problem becoming noticeable? Upgraded to 3.2
Please describe your problem. Running on Windows Server 2012 R2 against MS SQL 2012, on PHP 7.1.

Board runs fine, but when I open the admin console, I have a big red error at the top. There is no problem writing to the cache/production folder, because the rest of the board is writing to it just fine. Unsure of how to fix this error, or if it actually is an error?

phpBB encountered an error building the container due to an installed extension. For this reason, all extensions have been temporarily disabled. Please try purging your forum cache. All extensions will automatically be re-enabled once the container error is resolved. If this error continues, please visit phpBB.com for support.

Exception: Unable to write to the "./../cache/production" directory.
#0 {drive root}\forum\vendor\symfony\config\ResourceCheckerConfigCache.php(114): Symfony\Component\Filesystem\Filesystem->dumpFile('./../cache/prod...', 'write('load_extensions()
#3 {drive root}\forum\common.php(115): phpbb\di\container_builder->get_container()
#4 {drive root}\forum\adm\index.php(23): require('{drive root}...')
#5 {main}
Generated by SRT Generator

[david63]

That error message does not correlate with this

Do you have any extensions installed? No

The error message is saying that there is a problem with one, or more, of your extensions. You need to re-enable them one at a time until you find the culprit.

Incidentally this will normally only happen with non validated extensions.

[gsmaclean]

That error message does not correlate with this

Do you have any extensions installed? No

The error message is saying that there is a problem with one, or more, of your extensions. You need to re-enable them one at a time until you find the culprit.

Incidentally this will normally only happen with non validated extensions.

I have no extensions installed on my site. The only one that was installed was the VigLink extension that came with 3.2, and I disabled it with no change in this error.

[gsmaclean]

Incidentally, I did finally find the cause of this problem, and I'm posting it here in case anyone comes across the same problem in the future.

By default, the /forum/cache/production folder is created with permissions that allow for files to be written...except by symfony, for some reason.

I modified the /forum/cache/production folder, and changed the owner of the folder to IUSR (which is the default application pool user that the site will be running on under IIS unless you have modified it). I also added IUSR to the permissions for the folder, giving it full access. Then clear the cache, and the problem is fixed.

[3Di]

Exception: Unable to write to the "./../cache/production" directory.

That speaks books, indeed.

[gsmaclean]

Exception: Unable to write to the "./../cache/production" directory.

That speaks books, indeed.

Yes, but the site was writing to the /cache/production directory with no problem whatsoever. It was filling up with cached PHP files, the twig directory and all of its subdirectories were all being created and populated. I have no idea why the symfony cache would use some different kind of permissions to write its files, but giving explicit permissions to the IUSR account (even though it already had permissions by virtue of the group it belonged to) fixed the problem.