I’m starting to explore Yii2 and have encountered a problem that should be easy to solve but I haven’t figured out. After installing Yii2 and the basic template using Composer both the Home and About pages display fine, but the Contact and Login forms give me this error:
The directory is not writable by the Web process: C:\inetpub\wwwroot\basic\web/assets
(notice the slash / instead of backslash \ at the end)
I changed the folder’s permission to allow both IUSR and IIS_IUSRS write access but keep getting the same error.
I must mention that I have a number of Yii1 apps working successfully under Windows (7 and Server 2008) and IIS 7/7.5.
I beg to differ. The directory is set writable by IIS and IIS_IUSRS and it even contains assets:
C:\inetpub\wwwroot\basic\web\assets>dir
Volume in drive C has no label.
Volume Serial Number is B44A-0DFE
Directory of C:\inetpub\wwwroot\basic\web\assets
03/07/2014 08:25 AM <DIR> .
03/07/2014 08:25 AM <DIR> ..
03/05/2014 10:35 AM 13 .gitignore
03/05/2014 10:48 AM <DIR> 2d81daff
03/05/2014 10:48 AM <DIR> 41139ddd
03/07/2014 08:25 AM <DIR> 88b205cb
03/05/2014 10:48 AM <DIR> f9c5ab41
1 File(s) 13 bytes
6 Dir(s) 900,533,825,536 bytes free
C:\inetpub\wwwroot\basic\web\assets>
Here is the log:
in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\widgets\ActiveField.php at line 133
128129130131132133134135136137138 // __toString cannot throw exception
// use trigger_error to bypass this limitation
try {
return $this->render();
} catch (\Exception $e) {
trigger_error($e->getMessage());
return '';
}
}
/**
2. yii\base\Application::handleError()
3. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\widgets\ActiveField.php – trigger_error() at line 133
4. in C:\inetpub\wwwroot\basic\views\site\contact.php – yii\widgets\ActiveField::__toString() at line 32
2728293031323334353637 </p>
<div class="row">
<div class="col-lg-5">
<?php $form = ActiveForm::begin(['id' => 'contact-form']); ?>
<?= $form->field($model, 'name') ?>
<?= $form->field($model, 'email') ?>
<?= $form->field($model, 'subject') ?>
<?= $form->field($model, 'body')->textArea(['rows' => 6]) ?>
<?= $form->field($model, 'verifyCode')->widget(Captcha::className(), [
'options' => ['class' => 'form-control'],
5. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\View.php – require() at line 292
6. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\View.php – yii\base\View::renderPhpFile() at line 232
7. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\View.php – yii\base\View::renderFile() at line 135
8. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\Controller.php – yii\base\View::render() at line 307
9. in C:\inetpub\wwwroot\basic\controllers\SiteController.php – yii\base\Controller::render() at line 86
8182838485868788899091 Yii::$app->session->setFlash('contactFormSubmitted');
return $this->refresh();
} else {
return $this->render('contact', [
'model' => $model,
]);
}
}
public function actionAbout()
{
10. app\controllers\SiteController::actionContact()
11. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\InlineAction.php – call_user_func_array() at line 53
12. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\Controller.php – yii\base\InlineAction::runWithParams() at line 130
13. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\Module.php – yii\base\Controller::runAction() at line 585
14. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\web\Application.php – yii\base\Module::runAction() at line 77
15. in C:\inetpub\wwwroot\basic\vendor\yiisoft\yii2\yii\base\Application.php – yii\web\Application::handleRequest() at line 289
16. in C:\inetpub\wwwroot\basic\web\index.php – yii\base\Application::run() at line 13
8910111213require(__DIR__ . '/../vendor/yiisoft/yii2/yii/Yii.php');
$config = require(__DIR__ . '/../config/web.php');
$application = new yii\web\Application($config);
$application->run();
I tried the exact same setup on my CentOS virtual server and it worked fine, so the only difference is Windows/IIS. Any other ideas?
Nope. It’s set as per Windows default to a blue box (meaning “no attributes”) so it allows read/write access to its contents. My previous post showed a few asset folders already present. This is intriguing… thanks for your continuing help.
Oh man, not a PHP bug again! Last year it was a CSecurityManager Decryption Problem and now this…
The bug report is originally from 2011 for PHP 5.3 but it still hasn’t been resolved; as per Yii2 requirements I’m using PHP 5.4.19. The strange thing is that your notice prompted me to try the same thing in my home system (similar Win specs) and it worked fine. Now I’ll start debugging the differences between my work and home PC’s to find a solution; at least I’m at ease with it not being a Yii2 problem.
The problem was resolved by updating the PHP version from 5.4.19 to a newer one. At home I have 5.4.20 and it worked; at the office I upgraded to 5.4.26 and it finally worked. The PHP changelog for 5.4.20 never mentions this issue.
I’m sorry to report that the problem is not solved; there are still some pages that show the “directory not writable” error even after updating PHP.
The Composer installation script doesn’t set the directories to writable; this may be a Composer issue with Windows. Therefore I had to set the permissions manually.
I checked yii\web\AssetManager and Yii1’s CAssetManager and they both have similar code using PHP’s is_writable function. Since Yii1 works fine I’m unsure of what’s going on.
On my CentOS server everything works fine so it seems like a Windows issue.
I guess I’ll have to wait for other Windows users to report their findings to get a clue.
I have not encountered these issues on my Win 7 or Win 8 yet.
PS: I have Cygwin tools installed as well and accessible in the environment path. The slashes do not matter much due to this. You may want to check this in your install as well.
Thanks @samdark, I’ll keep looking. The thing is that I work for a Microsoft-centric outfit and it’s hard to go outside the gospel; the only things I’ve gotten away with are using PHP and in very few projects, MySQL. On the other hand, my personal side projects are on Linux/nginx/MySQL. Go figure…
It took me a half-day to realize the error. I find a post (ht.tp://blogs.iis.net/bills/loadUserProfile-and-IIS7-2D00-understanding-temporary-directory-failures) which talks about the permissions with files / directories involving a temp directory. I just gave it a try.
What i did:
I changed the identity of the DefaultAppPool from "ApplicationPoolIdentify" to "NetworkService" which has permissions to that temp directory and then everything went back to normal (No more write/read errors).
I’m not saying we’re not going to fix issues under IIS if these are reported. I’m saying that we’re not getting such reports and I think it is because IIS is relatively rare compared to Apache or nginx.
If you have problems under IIS, add issues to bug tracker or, if you managed to fix these, you’re more than welcome to create pull requests.
