Closed mccordgh closed 5 years ago
First thing to try would be changing your folder mounts:
folders:
-
map: ../
to: /home/vagrant/code
To
folders:
-
map: /Full/Path/To/Code/Project
to: /home/vagrant/code
@svpernova09 Ah I will do that. This project was setup by someone else and I didn't realize that might be an issue there, as it has worked for a few months that way.
Thanks!
It seems like changing ../
to the full path /Users/matthewmccord/Work/my-app
still has the same issues. After a vagrant destroy && vagrant up
it works fine, but once I vagrant reload
I still get the Facade Root error screen.
Here are screenshots of permissions if this will help (as I said before I only get an error trying to clear cache while INSIDE vagrant (via vagrant ssh
):
OUTSIDE vagrant:
INSIDE vagrant (via vagrant ssh
):
After a vagrant destroy && vagrant up it works fine, but once I vagrant reload I still get the Facade Root error screen.
This sounds like we're on to something.
Show me the full output of the following:
vagrant destroy -f && vagrant up && vagrant reload
Don't mess with permissions inside the VM on mounted folder shares. You'll only confuse yourself, Virtualbox, and Vagrant. And none of you will enjoy it.
@svpernova09 Yea, I definitely don't want to tinker with perms there haha.
So I ran this:
vagrant destroy -f &> vagrant_destroy_up_reload.log && vagrant up >> vagrant_destroy_up_reload.log && vagrant reload >> vagrant_destroy_up_reload.log
and here is the output: vagrant_destroy_up_reload gist
Is this what you are looking for?
So there are no services failing, nothing throwing errors, I would have to assume this is a problem with your code base and not Homestead.
@svpernova09 should I have run the logging with the --debug
flag?
I think some errors aren't reported without it, yea?
I don't think --debug
would help. From the logs, Vagrant is working and everything seems to be fine.
Is there anything in /var/log/nginx/
for the site? might give you more info, but I would backtrace the Laravel stack trace at this point.
@svpernova09
$ less /var/log/nginx/my-app.test-error.log
seems to be the Facade Root error info:
2019/06/04 00:36:07 [error] 1019#1019: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught RuntimeException: A facade root has not been set. in /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php:234
Stack trace:
#0 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(397): Illuminate\Support\Facades\Facade::__callStatic('replaceNamespac...', Array)
#1 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(374): Illuminate\Foundation\Exceptions\Handler->registerErrorViewPaths()
#2 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(289): Illuminate\Foundation\Exceptions\Handler->renderHttpException(Object(Symfony\Component\HttpKernel\Exception\HttpException))
#3 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(188): Illuminate\Foundation\Exceptions\Handler->prepareResponse(Object(Illuminate\Http\Request), Object(Symfony\Component\Http" while reading response header from upstream, client: 192.168.33.1, server: stewart.test, request: "GET /live-rides HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm.sock:", host: "stewart.test", referrer: "http://stewart.test/notifications"
$ less /var/log/nginx/error.log
shows nothing.
Diving in to the Laravel source, I notice that symfony's Finder isn't returning any files for the config path:
vender/laravel/framework/src/Illuminate/Foundation/Bootstrap/LoadConfiguration.php
Line 82: method getConfigurationFiles()
Finder::create()->files()->name('*.php')->in($configPath)
The foreach
isn't even being executed because Finder::create()->files()->name('*.php')->in($configPath)
is returning []
instead of an array of config files...
The var $configPath
is correct "/home/vagrant/code/web/config"
Somehow it's just not able to access the files or something??
The only entries in my log file at storage/logs/laravel-2019-06-03.log
are for a stack trace due to an error caused by not running migrations before trying to access the db.
Really odd stuff.
Here's something I'd try:
Clone a FRESH copy of the project and set it up, don't change any permissions at all. Spin up a new Homestead box and see if you get the error.
All of the project files in any folder you map through Vagrant should be owned by the user you run the vagrant command as and will be assigned the same permissions to the vagrant
user inside the VM.
/cc @driesvints does this issue sound like permissions related? I've ruled out Homestead as much as I can.
@mccordgh are you using Lumen? Did you enable $app->withFacades();
in your bootstrap.php
? Does the app run with Valet? Can you upload a repo with the app which reproduces the problem?
@svpernova09 I'm not sure. What sync driver is being used by default? NFTS?
I'm not sure. What sync driver is being used by default? NFTS?
Looks like the default Virtualbox, which means any permissions existing on the shared filesystem BEFORE vagrant up will be translated exactly into the VM.
@svpernova09 created a dir called fresh_test
and cloned the repo for the project in to this new dir, and did all the setup.
After first vagrant up
everything worked as expected.
After first vagrant reload
same Facade Root error:
Pretty much what I expected, as I've nuked my local repo before and set it all back up trying to see if that would fix things as well. Same thing happened as above, first up was great, on a reload broken.
@driesvints I'm using a full install of Laravel 5.8.
I've been building this project for a clients for several months now, and never had a single issue with reloading vagrant until last week all of a sudden.
Tried to setup Laravel Valet, and I'm just getting 404 - Not Found
from that. It's my first time using Valet, so I may be doing something wrong. It seems pretty straight forward though... I have a top level dir my-app
(this is the top level repo dir) which holds a few projects within it. web
folder is the laravel project
my-app/
+
+-- web/
+
+-- other_project/
I installed valet via composer and valet install
, navigated to my-app
ran valet park
then tried to navigate to http://web.test
but I get 404 - Not Found
:/
using php -S localhost:8002
from my public/
dir I can get the login screen to appear, but it wont do much beyond that because Laravel needs to be involved I guess.
This seemed to start around the time I updated from OS X Mojave 10.14.4 to 10.14.5 The change notes for 10.14.5 are pretty short and the only thing I can think of that maybe could be affecting things might be kernel extensions related, but I have no idea if any of this is using kernel extensions
OS X Mojave 10.14.5 change notes
After the Mojave update, I also updated Laravel from 5.7 to 5.8, VirtualBox, Homestead from 7.x to newest 8.x
I don't think it was the Mojave update, just that the Mojave update needed me to restart my machine, which brought down vagrant and then when I brought it back up I was getting the Facade Root error.
(And as I mentioned earlier, clearing the cache can get me past Facade Root error, but then I just get a permissions error on storage/logs which seems to be a false flag?)
EDIT:
Using php artisan serve
with the vagrant box up and just acting as a mysql server, everything works as expected on first vagrant up
AND after vagrant reload
!!
Try using the latest stable, non-alpha release of Homestead, Should be Homestead v8.5.4, and base box v7.2.1
Does the facade code work if you drop only enough of that code into a new project?
laravel new test-homestead
cd test-homestead
composer require laravel/homestead
php vendor/bin/make
<Add laravel facade code>
vagrant up
That will spin up a new project and Homestead
@svpernova09 I followed the docs here to update homestead: https://laravel.com/docs/5.8/homestead#updating-homestead
vagrant box update
results in:
==> web: Checking for updates to 'laravel/homestead'
web: Latest installed version: 8.0.0-alpha2
web: Version constraints: >= 7.2.1
web: Provider: virtualbox
==> web: Box 'laravel/homestead' (v8.0.0-alpha2) is running the latest version.
changing laravel/homestead
to ^8
in composer.json and running composer update
, then vagrant box list
results in:
laravel/homestead (virtualbox, 6.3.0)
laravel/homestead (virtualbox, 7.2.1)
laravel/homestead (virtualbox, 8.0.0-alpha2)
(I'm assuming the multiple versions are due to having a few different projects on my machine because I work for an agency)
This current project is the only one I've updated homestead with, so I assume it's the v8.0.0-alpha2. I'm not sure 100% how to tell which of those 3 in the list maps to the project in my current dir though.
Should laravel/homestead
be updating to 8.5.4??
Edit: confirmed my current project is on v8.0.0-alpha2 by $ cat ~/.vagrant.d/data/machine-index/index
, pretty printing the json and reading through it:
...
"extra_data":{
"box":{
"name":"laravel/homestead",
"provider":"virtualbox",
"version":"8.0.0-alpha2"
}
}
...
as far as your second post about the facade code, I'm not sure what actual Facade Code is erroring. I'm almost certain it's in the bootstrapping of Laravel as the error seems to be in the nginx my-app-error.log
file and not in the laravel log file.
Add version: 7.2.1
to Homestead.yaml
and it'll lock you to that version of the base box, for The Homestead version, either use the v8.5.5 tag or check out the release branch and make sure it's up to date
@svpernova09
I added version: 7.2.1
to my Homestead.yaml
I updated composer.json
to "laravel/homestead": "^8.5.5" I ran
composer update I ran
vagrant destroy -f && vagrant up Still the same v8.0.0-alpha in
vagrant box list`
The docs say
If you cloned the repository you can run the following commands at the location you originally cloned the repository:
But I just have homestead installed via composer, so I'm not sure if I can do that or what. I'm not sure of how to get my version up past 8.0.0-alpha2 right now :/
ps. Thank you for all of the help so far.
Open composer.json
and change the version Homestead is set to dev-release
, this will tell composer to pull down the release branch for you, which is always the latest stable tag.
@svpernova09 I think we may have found something....
I completely deleted the vagrant box
ran vagrant box update
and I'm at v7.2.1 now
set composer.json
entry "laravel/homestead": "dev-release"
ran composer update laravel/homestead
ran vagrant up
and migrations: everything worked as expected
ran vagrant reload
and everything worked as expected
So I guess it is a box v8.0.0-alpha2 issue??
So I guess it is a box v8.0.0-alpha2 issue??
Must be. Which will be fun for me to try to debug. Glad you got it sorted out.
I have just installed the latest stable today. However, the same issue seems to persist.
Same here.
I have just installed the latest stable today. However, the same issue seems to persist.
- Homestead v9.0.0
- Settler v8.0.0
I am having the same problem. Everything was working well with vagrant 2.2.2 and homestead 7.2 My setup vagrant 2.2.5, homestead box 8.0.0 windows 10 This is what I did.
This has to be a permissions related error in homestead
In my other project, I created a simple test program with Symfony/Finder
`
require('../vendor/autoload.php');
use Symfony\Component\Finder\Finder;
$f = new Finder();
$f->files()->in('../config');
if($f->hasResults()) {
echo "Has results\n";
}else{
die("didn't get anything");
}
foreach ($f as $file) {
$absoluteFilePath = $file->getRealPath();
$fileNameWithExtension = $file->getRelativePathname();
echo "$absoluteFilePath => $fileNameWithExtension\n";
}`
When I run this on my laptop, it returns the folder content as intended. When I run it via virtual homestead (either web host or via ssh commandline,), it fails
It seems to be a permissions error in homestead. All file permissions look correct ( drwxrwxrwx 1 vagrant vagrant 0 Jul 6 20:03 ./ drwxr-xr-x 12 vagrant vagrant 4096 Jul 6 20:42 ../ -rwxrwxrwx 1 vagrant vagrant 60 Jul 6 19:59 composer.json -rwxrwxrwx 1 vagrant vagrant 2204 Jul 6 19:59 composer.lock drwxrwxrwx 1 vagrant vagrant 0 Jul 6 20:01 public/ drwxrwxrwx 1 vagrant vagrant 0 Jul 6 20:04 vendor/
Can't be a nginx problem because I get the Finder loading problem even from the CLI (Vagrant destroy && vagrant up gist) https://gist.github.com/ksorbo/c656ca3517d02cf4b123ed4a0939f0fa
@svpernova09 I think we may have found something....
set
composer.json
entry "laravel/homestead": "dev-release"
I can't find where this setting is at. Is this in the Laravel project composer.json? I am using a global Homestead folder and it has no require entry for laravel/homestead
Please stop adding into this thread with "me too" or "same issue here", this isn't helpful. Please open new issues and show the FULL log of vagrant destroy && vagrant up
and the rest of the issue template. It's really difficult to debug without a full report.
As many others, I have also had this problem for a little while now. Now, after reading this thread, i got my homestead working again, but I had to go all the way back to version homestead version 8.6.0, or else it will download a homestead box 8.0.0 that does not work either... If you use dev-release as mentioned in this thread, it will try and download box version 8.0.0, and then I get the error.
So what I did was:
vagrant destroy
composer update
vagrant up
so now I am running on box version 7.2.1 - and it is working (the last working version i have tried so far)
Hope this helps anyone
@dennis-nielsen
If box 8.0.0 doesn't work for you, and you're using Virtualbox 6, please post an issue with the details. Rolling back to old versions helps no one, and makes it harder on me to help people. Users should be keeping up to date with the latest versions of the repo and the base box.
@svpernova09 I know it doesnt help finding the issue, but it helps me getting past it so I can continue on my project.
You mentioned Virtual box 6? Actually I am on version 5.2.30 because I remember having other problems with vagrant on version 6. Maybe I should try version 6 again
@svpernova09 I know it doesnt help finding the issue, but it helps me getting past it so I can continue on my project.
Trust me I know! Sometimes you gotta pay the bills first. I get it.
You mentioned Virtual box 6? Actually I am on version 5.2.30 because I remember having other problems with vagrant on version 6. Maybe I should try version 6 again
We've been supporting Virtualbox 6 for a while now, and it looks like v8.x/v9 is the hard cutoff that we're not able to support v5 anymore. I wish I could plan for that better, but it's pretty difficult to track that info.
@dennis-nielsen
If box 8.0.0 doesn't work for you, and you're using Virtualbox 6, please post an issue with the details. Rolling back to old versions helps no one, and makes it harder on me to help people. Users should be keeping up to date with the latest versions of the repo and the base box.
I was experiencing same problem in this thread, but was still on VirtualBox 5.2.30
on Mac OS.
I upgraded to VirtualBox 6 and now everything is working!! Thank you!
Posting this per @svpernova09 's advice from a laracasts post (linked at bottom)
Versions
2.2.4
Version 5.2.30
8.0.0-alpha2
Host operating system
OS X Mojave
10.14.5
Homestead.yaml
Vagrant destroy & up output
vagrant destroy gist
vagrant up gist
Expected behavior
After
vagrant --reload
or avagrant halt && vagrant up
I should be able to access my web app atmy-app.test
.Actual behavior
vagrant --reload
or avagrant halt && vagrant up
, I get this error screen when trying to navigate tomy-app.test
:If I run (from OUTSIDE the vagrant box):
$ php artisan cache:clear
$ php artisan route:cache
$ php artisan config:cache
$ php artisan view:clear
I can get "past" this error screen, but then get a new one saying that "[...]/storage/logs" does not exist and could not be built: Permission Denied:If I try to run any of those cache clearing commands from INSIDE vagrant (after
vagrant ssh
), I get this error:Permissions seem to be a false flag as I've tried changing permissions, etc and the directory definitely does exist.
I haven't found anyway to get any further besides doing
vagrant destroy && vagrant up
again. But, of course, the errors begin again anytime I do avagrant reload
orvagrant halt && vagrant up
or restart my machine, etc.Steps to reproduce
$ vagrant up
to bring box up$ vagrant reload
or$ vagrant halt && vagrant up
References
I arrived here through these links: