It appears that the issue has been reported by others here:
https://github.com/mitchellh/vagrant/issues/5199

On Thu, Feb 12, 2015 at 3:37 PM, Andrew Kerr <[email protected]> wrote:

> Hi all,
>
> This is definitely a major problem with version 1.7.2, since Vagrant
> mounts Chef-related shared folders in /tmp/vagrant-chef by default.  Should
> the default provisioning_path be moved out of /tmp, since it is normally
> cleared on reboot?
>
> As a workaround, we will try overriding provisioning_path in Vagrantfile
> to something not in /tmp.
>
> Thanks,
> Andrew
>
>
> On Fri, Jan 30, 2015 at 5:27 PM, Alvaro Miranda Aguilera <
> [email protected]> wrote:
>
>> hello, not sure if this is related to the same
>>
>> but can you try
>>
>> on the guest: mount
>>
>> then on the host
>> vagrant reload --provision
>>
>> and see if works or not? and compare the mounts available?
>>
>> it seems that some folders are calculated for provisioner, and then don't
>> get mounted in a reload without provision.. i have seen this on puppet, not
>> sure if will be the same in chef..
>>
>>
>> On Sat, Jan 31, 2015 at 7:50 AM, Mariano <[email protected]> wrote:
>>
>>> Hi Everyone, first at all I'd like to say congratulations for those who
>>> are participating on the great Vagrant stuff, this has been very useful on
>>> my day to day, now let's talk about the issue I have been seeing this since
>>> upgrade from vagrant 1.7.1 to 1.7.2,
>>>
>>> All time I make a vagrant reload I get this error:
>>> Running provisioner: chef_solo...
>>> Shared folders that Chef requires are missing on the virtual machine.
>>> This is usually due to configuration changing after already booting the
>>> machine. The fix is to run a `vagrant reload` so that the proper shared
>>> folders will be prepared and mounted on the VM.
>>>
>>> So I made some research  about this and I found this commit:
>>>
>>>
>>> https://github.com/mitchellh/vagrant/commit/155516fb6c8a4025b38d5b709b886f5d02a33a27#diff-4b59695a716db3067f2a3b5d98bff333
>>>
>>>
>>> where the the file chef_solo.rb has been changed, so now you have this
>>> new structure, where, as you can see, now synced_folders has a new option
>>> cached:true,
>>>
>>> +          existing = synced_folders(@machine, cached: true)
>>> +          share_folders(root_config, "csc", @cookbook_folders, existing)
>>> ...
>>>
>>> The main problem with this is if you have a base machine with the
>>> following setting  on  /etc/default/rcS
>>>
>>> # delete files in /tmp during boot older than x days.
>>> # '0' means always, -1 or 'infinite' disables the feature
>>> #TMPTIME=0
>>>
>>> everytime you reload the machine the tmp directory is erased and all the
>>> folders inside.
>>>
>>> When we use that configuration, vagrant try to get a synced folder like
>>>  /tmp/vagrant-chef/<some random number>/<synced_folder>, and it's not
>>> there any more just because the above explanation.
>>>
>>> The solution I found was to set the cached param to false and It worked
>>> fine.
>>>
>>> So could be possible to change that cached param to be variable? or
>>> maybe make some check before sync folders so if they doesn't exists in the
>>> cached one just add them and continue?
>>>
>>> Any thought about this would be great.
>>>
>>> Thanks for your time.
>>>
>>> Mariano.
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Vagrant" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Vagrant" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Andrew Kerr
>



-- 
Andrew Kerr

-- 
You received this message because you are subscribed to the Google Groups 
"Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to