We’re happy to hear it. When people post on the forum with just an error and say “This is the error message I get. I’m not sure what do do here.”, we don’t know any of that. We also don’t have much to go on to help you.
2 Likes
Hey @swalkinshaw, Yes it follows the directory and the system requirements are installed. Under the current directory there was just an empty directory called web and a .env file with the correct variables for the db_password, site, login and all that…but that was it. No composer file…am I to manually install or create one there too, b/c the docs make no mention of that.
I understand @kalenjohnson that you don’t have much to go to help me, which is why I would expect follow up questions from people who do know what they are doing to help me figure it out. I am learning this Roots toolset, I’m following the docs to a “t”, and when I or others post an error and only saying “I don’t know what to do here”, it’s b/c it’s all I got back from the computer too. I don’t know what else more I can say or what other information I can give, much less what to look for, unless I’m asked so I can provide it. An alternative I can think of is just writing a huge page full of what could be unrelated info like the machine I’m on or editor or whatever. I like what @swalkinshaw did and gave me something to look for so I can help me help me, I much prefer that than people seeing my simple error code and question and just moving on. I don’t know…I’m just really frustrated. ha
This means that Vagrant shared folder feature hasn’t worked apparently. Vagrant “shares” (syncs) the root directory on your host machine to the virtual machine. If that isn’t working, nothing will.
Please do the following in your trellis project directory:
vagrant destroyrm -rf .vagrantvagrant up
Then copy and paste the entire Vagrant log in here.
I tried those commands but now nothing at all shows up beneath the /srv/ directory
I’m getting the vagrant log
Where would I find the log you need at? I’m still unfamiliar with this Vagrant software, having second thoughts 
Just to triple check, and I think the answer is yes, but does your mac (the “host” machine; not the VM) have the bedrock files in example.com/site directory, including the composer.json file? See discussion (and how local_path variable functions). If the files are not there, you need to clone bedrock to that site directory and vagrant reload --provision
If the files (including composer.json) are present in the site directory on your mac (host machine), it indeed suggests a problem with the syncing of site into the VM at current. You mentioned that the “etc/hosts address has been uncommented.” I hope that means you do have a 127.0.0.1 localhost entry in your /etc/hosts, which would affect whether the nfs sync dirs work (details). If you had to uncomment or add this entry, you may then need to repeat some steps you’ve tried such as vagrant destroy, double-check /etc/exports, etc., maybe even uninstall and reinstall vagrant.
As for vagrant log, you could just post the output that appears in your console when you run vagrant up. In rare cases of investigating tricky vagrant issues, you can boost the verbosity of the vagrant output, e.g., with vagrant up --debug (vagrant debugging details), which also mention option to output to log file: vagrant up --debug &> vagrant.log).
I do not see the same composer.json issue when I do a fresh vagrant up with the same specs:
System info:
Ansible 2.4.1.0; Vagrant 2.0.1; Darwin
Trellis at "Fix `raw_vars` functionality for Ansible 2.4.1"
Here is a link to a gist of the vagrant log/output on my console right before the error: https://gist.github.com/adrianvalenz/c71b9e41626cedebece1c264d3e3c3e6
I tried making a new site and I really don’t know what is going on.
@fullyint I’m about to read your latest reply now
Hope its ok to share this.
So it is uncommented, but always has been.
The composer.json file is in example.com/site in my “host” machine, not VM.
The local_path does point to ../site
I’ve tried vagrant destroy and double-checking /etc/exports and all… 
I’m really stumped :*(
Oh and here is the vagrant.log with the --debug option
https://gist.github.com/adrianvalenz/49a0e341f90ae69906df1c067502ff15
I just now uninstalled and reinstalled vagrant via homebrew, and only reinstalled virtualbox…
If I can’t figure this out in the next hour, this is too much stress and I’m not even sure if I will like the workflow, such a bummer. I am still interested in using Bedrock and I have enjoyed Sage for months now, but I just really want a nice workflow that I can enjoy in a similar way when developing Rails applications. I see the value of WordPress for end users/clients, but dev workflow for years has been disgustingly sloppy, which is why I really want this Trellis to work…even if I get it working, I still have to figure out if I can use it with Dokku or just plain DigitalOcean. I know I have more headaches to come.
You need a server running a bare/stock version of Ubuntu 16.04 Xenial. If you’re using a host such as DigitalOcean, then just select their Ubuntu 16.04 option.
2 Likes
Reviewing your /etc/hosts, it appears you may have multiple vagrant VMs active, which normally isn’t a problem, but troubleshooting is often a process of simplifying as much as possible, so you may want to shut down or destroy those VMs while troubleshooting the current issue (remember to export DB and save files before destroying).
When you resolve the current issue and later attempt to load the timewisestudios.com domain in your browser, it could likely be a problem that you may have additional VMs with the same IP of 192.168.50.5. If these are each Trellis VMs, set a different IP for each. If these other VMs no longer exist, you’ll want to remove their entries from your /etc/hosts file. Once the VMs are halted/destroyed, it may work to simply run vagrant hostmanager. Otherwise you may need to manually remove those entries.
To help identify running VMs, try vagrant global-status. Also load the VirtualBox GUI to see and shut down running VMs, especially any that may have somehow been orphaned/abandoned by Vagrant (i.e., of which vagrant somehow lost control).
The biggest issue I noticed so far, however, is that your VM boot output shows nothing related to sync dirs or file mounts. Compare your opening output (non-debug version) with the following output I get:
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/ubuntu-16.04'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/ubuntu-16.04' is up to date...
==> default: Setting the name of the VM: example.dev
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
==> default: Mounting NFS shared folders...
==> default: Mounting shared folders...
default: /vagrant => /Users/philip/projects/roots/example.com/trellis
==> default: Checking for bindfs in VM...
default: Package manager detected: apt-get
default: Fuse kernel module is installed
default: Fuse kernel module is loaded
==> default: Bindfs seems to not be installed on the virtual machine, installing now
default: Bindfs 1.12.6 is installed
==> default: Machine is ready to use bindfs!
==> default: Creating bind mounts after synced_folders...
default: /vagrant-nfs-example.com => /srv/www/example.com/current
default: /ansible-nfs => /home/vagrant/trellis
default: /home/vagrant/trellis/bin => /home/vagrant/trellis/bin
==> default: [vagrant-hostmanager:guests] Updating hosts file on active guest virtual machines...
==> default: [vagrant-hostmanager:host] Updating hosts file on your workstation (password may be required)...
==> default: Running provisioner: ansible...
Vagrant has automatically selected the compatibility mode '2.0'
according to the Ansible version installed (2.4.1.0).
Alternatively, the compatibility mode can be specified in your Vagrantfile:
https://www.vagrantup.com/docs/provisioning/ansible_common.html#compatibility_mode
default: Running ansible-galaxy...
<snip>
default: Running ansible-playbook...
<snip>
PLAY [WordPress Server: Install LEMP Stack with PHP 7.1 and MariaDB MySQL] *****
<snip>
- Have you modified the
Vagrantfileor thevagrant.default.ymlat all? Especially in a way that could have disabled all the Vagrant sync functionality? - Do you have other vagrant-related projects/code running on your machine that could be conflicting? Like some kind of global Vagrant settings for your machine generally, which could be interfering? I’m not familiar with Local by Flywheel, but perhaps some of its settings are conflicting.
WE did it!!!
I specified the directories Local by Flywheel has access to in the /etc/exports file and after destroying/double-checking duplicate sites…
Thank you so much @fullyint for your help and taking the time to respond to my questions and all. 
4 Likes
How can I make my topic listed vs unlisted?
Thanks @adrianvalenz @fullyint and Roots team for working this. I downloaded Local by Flywheel several weeks ago out of curiosity, but it seems to alter a lot of things that mess with setups like Trellis.
Happy to report that removing all Local by Flywheel references in /etc/exports solved this issue for me too on MacOS HSierra.
1 Like