Vagrant: NFS folders not properly synced on macOS High Sierra

[Yaroon]

Please note that the Vagrant issue tracker is reserved for bug reports and
enhancements. For general usage questions, please use the Vagrant mailing list:
https://groups.google.com/forum/#!forum/vagrant-up. Thank you!

Vagrant version

$ vagrant -v
Vagrant 1.9.7

Host operating system

$ uname -a
Darwin liver.local 17.0.0 Darwin Kernel Version 17.0.0: Thu Jun 29 19:47:09 PDT 2017; root:xnu-4532.0.0.0.1~23/RELEASE_X86_64 x86_64
$ sw_vers -productVersion
10.13

Guest operating system

$ uname -a
Linux vagrant 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) x86_64 GNU/Linux

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

## Check dependencies

# vagrant version
Vagrant.require_version ">= 1.7.0"


# vagrant-triggers plugin
if !Vagrant.has_plugin?("vagrant-triggers")
  puts "The 'vagrant-triggers' plugin is required, install it with the following command:"
  puts " vagrant plugin install vagrant-triggers"
  exit
end
# vagrant-bindfs plugin
if !Vagrant.has_plugin?("vagrant-bindfs")
  puts "The 'vagrant-bindfs' plugin is required, install it with the following command:"
  puts " vagrant plugin install vagrant-bindfs"
  exit
end


Vagrant.configure("2") do |config|

  # General configuration, valid for all defined boxes.

  # Virtualbox tweaks.
  config.vm.provider :virtualbox do |vb|
   # Moar memory
    vb.customize ["modifyvm", :id, "--memory", "2048"]
    # allow symlinks
    vb.customize ["setextradata", :id, "VBoxInternal2/SharedFoldersEnableSymlinksCreate/vagrant", "1"]
  end

  # NFS shares
  config.vm.synced_folder "www", "/var/www", type: "nfs" 
  config.vm.synced_folder "db", "/home/vagrant/db", :nfs => true
  config.vm.synced_folder "scripts", "/home/vagrant/scripts", :nfs => { :mount_options => ["mfsymlinks"] }

  #config.vm.synced_folder "www", "/home/vagrant/www", type: "nfs"
  #config.bindfs.bind_folder "/home/vagrant/www", "/var/www", owner: "vagrant", group: "vagrant", perms: "0777"

  # https/ssl port forwarding
  config.vm.network :forwarded_port, guest: 443, host: 4444

  # SSH
  config.ssh.shell = "BASH_ENV=/etc/profile bash -l"

  ## Provision
  # setup.sh will run to provide additional provisioning, see script for details
  config.vm.provision :shell, :inline => "
    /vagrant/scripts/setup.sh;
  "

  ## Triggers

  # cleanup actions that will run on 'destroy'
  config.trigger.before :destroy do
    for script in Dir.glob("scripts/cleanup/*")
      begin
        answer = ''
        info("Do you want to execute the '#{script}' cleanup script'? [Y/n] ")
        Timeout::timeout(5) { answer = $stdin.gets }
      rescue Timeout::Error
        answer = 'y'
      end
      if answer == 'Y' or answer == 'y'
        run "vagrant ssh -c 'sh #{script}'"
      end
    end
  end

  # the box
  config.vm.define :vagrant do |vagrant|
    vagrant.vm.network :private_network, ip: "192.168.50.2"
    vagrant.vm.hostname = "vagrant.loc"
  end
end

if File.file?('Vagrantfile.box')
  load 'Vagrantfile.box'
end

Please note, if you are using Homestead or a different Vagrantfile format, we
may be unable to assist with your issue. Try to reproduce the issue using a
vanilla Vagrantfile first.

Debug output

https://gist.github.com/Yaroon/dcb20eb984669688746767b0342c7d55

Expected behavior

I should see all folders that in the NFS share.
I shouldn't see folders doubly in the NFS share.

Actual behavior

I do not see the TypedData folder.
I see Field and Breadcrumb folder twice.

Steps to reproduce

1. You can try installing Drupal 8.3 on your host.
2. Then set up Vagrant file so that the www folder gets shared to the guest OS's /var/www
3. Check out /var/www/core/lib/Drupal/Core and you'll see some folders differently from the host OS.

Additionally you can check out a screencast I did that illustrates the problem.
You can see how the folder is an NFS folder at first. You can see Breadcrumb and Field appearing twice on the guest OS while TypedData does not. When I then create a folder "WhateverOtherData" it gets synced between host and guest. However TypedData and Field and Breadcrumb are still there twice. When I then create a folder StringData, all of a sudden TypedData appears on the guest and we only see 1 Breadcrumb and 1 Field folder. So something got triggered to fix it... I just don't know what.

https://www.dropbox.com/s/ykdi1cp5v689sq0/Vagrant%20%2B%20NFS%20%2B%20macOS%20High%20Sierra.mov?dl=0

References

[pascaldevink]

I've also been seeing the same "behaviour" since upgrading to 10.13, but only with some vagrant boxes.

For those reading this coming from google; changing from NFS to rsync is a good workaround for the problem for now, but requires extra actions (such as running vagrant rsync-auto in the background) and has some small drawbacks.

[briancain]

Hello @Yaroon - I attempted to reproduce this locally with my own local Drupal folder being synced with NFS and I did not notice duplicate folders within the mounted folder on /var/www like you mentioned. If you could destroy your current guest (make sure to back up anything important before doing so), restart your host, and bring up a fresh guest and see if your problem still persists.

Thank you!

[Yaroon]

I've 'vagrant destroy'ed the box, and rebooted the computer. Still the same, as soon as I remove the "StringData" folder, "TypedData" goes away as well. When I create "StringData" again, it re-appears.

Maybe next week Wednesday there'll be a new macOS High Sierra Public beta. We'll see how it evolves? Until then, I don't know what to do. macOS HS does of course have a new FS... that could be the cause? But I don't know nearly enough about it in order to gain some info that could diagnose this issue.

[kikitux]

@Yaroon can you try to reproduce in a more simple setup?

I wasn't able.

vagrant@precise64:~$ touch /var/www/www_from_guest /home/vagrant/db/db_from_guest /home/vagrant/scripts/scripts_from_guest
vagrant@precise64:~$ ls -al /var/www/ /home/vagrant/db /home/vagrant/scripts                   
/home/vagrant/db:
-rw-rw-r-- 1     501 dialout    0 Jul 19 19:25 db_from_guest

/home/vagrant/scripts:
-rw-rw-r-- 1     501 dialout    0 Jul 19 19:25 scripts_from_guest

/var/www/:
-rw-rw-r--  1  501 dialout    0 Jul 19 19:25 www_from_guest
vagrant@precise64:~$ logout


0 kikitux ~/Dropbox/local/kikitux/p64 (master) $ ls db scripts www
db:
db_from_guest

scripts:
scripts_from_guest

www:
www_from_guest
0 kikitux ~/Dropbox/local/kikitux/p64 (master) $ touch db/db_from_host scripts/scripts_from_host www/www_from_host
0 kikitux ~/Dropbox/local/kikitux/p64 (master) $ ls db scripts www
db:
db_from_guest  db_from_host

scripts:
scripts_from_guest  scripts_from_host

www:
www_from_guest  www_from_host
0 kikitux ~/Dropbox/local/kikitux/p64 (master) $ vagrant ssh 


vagrant@precise64:~$ ls -al /var/www/ /home/vagrant/db /home/vagrant/scripts
/home/vagrant/db:
total 8
drwxr-xr-x 4     501 dialout  136 Jul 19 19:26 .
drwxr-xr-x 6 vagrant vagrant 4096 Jul 19 19:23 ..
-rw-rw-r-- 1     501 dialout    0 Jul 19 19:25 db_from_guest
-rw-r--r-- 1     501 dialout    0 Jul 19 19:26 db_from_host

/home/vagrant/scripts:
total 8
drwxr-xr-x 4     501 dialout  136 Jul 19 19:26 .
drwxr-xr-x 6 vagrant vagrant 4096 Jul 19 19:23 ..
-rw-rw-r-- 1     501 dialout    0 Jul 19 19:25 scripts_from_guest
-rw-r--r-- 1     501 dialout    0 Jul 19 19:26 scripts_from_host

/var/www/:
total 8
drwxr-xr-x  4  501 dialout  136 Jul 19 19:26 .
drwxr-xr-x 12 root root    4096 Jul 19 19:23 ..
-rw-rw-r--  1  501 dialout    0 Jul 19 19:25 www_from_guest
-rw-r--r--  1  501 dialout    0 Jul 19 19:26 www_from_host
vagrant@precise64:~$

[kikitux]

my Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "hashicorp/precise64"
  config.vm.network "private_network", type: "dhcp"

  # NFS shares
  config.vm.synced_folder "www", "/var/www", type: "nfs" 
  config.vm.synced_folder "db", "/home/vagrant/db", :nfs => true
  config.vm.synced_folder "scripts", "/home/vagrant/scripts", :nfs => { :mount_options => ["mfsymlinks"] }

end

[kikitux]

@Yaroon for most use cases NFS is fine.

however if you are using a code generator that may use links, symlinks, hardlinks, etc, it may require a full FS and wont' work with virtualboxfs, vmware hgfs or nfs.

we have seen nodejs and php apps having issues due this.

vagrant does his best to setup nfs for you, however, once is setup, will be host + guest troubleshooting in case of issues.

if you think this is a core vagrant issues, please help us to reproduce this on a simple vagrantfile and simple commands.

thanks!

[pascaldevink]

I'm not sure if this is a vagrant issue per se, could be an NFS implementation issue in High Sierra, or be caused by APFS. One thing I do know, is that I'm using the exact same vagrant box and codebase as before I upgraded. And I didn't have any trouble before that.

I've been trying to come up with a simple reproduction vagrantfile, but unfortunately I wasn't able to. It doesn't even occur on all the vagrant boxes that I have, which makes it hard to pinpoint the problem.

Is there any way to get more debugging output from the NFS process?

[Yaroon]

I'll also try to come up with something reproducible for you guys, but it'll be tough I think. I'm really hoping for a fix in macOS High Sierra next week. Thing is, I don't know if Apple is aware, and it's hard to write a bug report without a true reproducible for those guys. It won't easily be looked at then.

[kikitux]

please reopen if found a way to reproduce

[Yaroon]

So I've found a reproducible. Again, I am on macOS High Sierra.

I don't know how to re-open an issue either, so I hope someone sees this :)

I don't quite not know how to go about it, but this is what I did to get it going... I'll include some commands you need to execute on the vagrant box to get to the point where you see some folders not sync.

Vagrant version: Vagrant 1.9.7
VirtualBox version: Version 5.1.26 r117224 (Qt5.6.2)
My Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "debian/jessie64"
  config.vm.network "private_network", type: "dhcp"
  config.vm.synced_folder "www", "/var/www", type: "nfs"
end

In vagrant I added these to /etc/apt/sources.list

deb http://http.debian.net/debian jessie-backports main contrib non-free
deb-src http://http.debian.net/debian jessie-backports main contrib non-free
deb http://packages.dotdeb.org jessie all
deb-src http://packages.dotdeb.org jessie all

So I could, on the vagrant box:

$ apt update && apt-get install virtualbox-guest-additions-iso build-essentials linux-headers-3.16.0-4
$ mount /usr/share/virtualbox/VBoxGuestAdditions.iso /media/cdrom && /media/cdrom/VBoxLinuxAdditions.run
$ mkdir /var/www

Then on the Host, download Drupal from https://www.drupal.org/project/drupal/releases/8.3.7
Extract the archive and rename the drupal folder to www, as this is the folder that we'll share to the guest's /var/www

Then... after vagrant up, in guest you can go to /var/www/core/lib/Drupal/Core/ and you won't see the TypedData folder, even though it is there on the host.

If you mkdir StringData in /var/www/core/lib/Drupal/Core/ you'll all of a sudden see the TypedData folder appear as well.

Let me know if you need more instructions.

[Yaroon]

Booting the machine in VirtualBox, not through vagrant, does show the folder...

In VirtualBox: add the www folder as a permanent Machine Folder with Folder Name drupalwww

Add root to the vboxsf group

$ sudo usermod -a -G vboxsf root

Mount the shared folder

$ sudo mount -t vboxsf drupalwww /var/www

List the folder's contents

$ ls /var/www/core/lib/Drupal/Core

This lists the TypedData folder. When booting the machien via vagrant up, using NFS to share the folder, it does not show.

[Yaroon]

Or, when not doing it via VirtualBox' shared folders but configuring the NFS share on the guest OS it also works well.

Adding the line to /etc/fstab for my host's IP and www folder lets me mount it and there are no missing files or folders.
127.28.128.1:/Users/jeroen/Projects/VagrantTest/www /var/www nfs defaults 0 0

[Yaroon]

It got even simpler, it's probably an APFS bug that causes it to not work well with NFS, so I think this will blow up soon as macOS High Sierra nears release, here's some commands I ran to show the problem. No Drupal install needed, just a vagrant box.

```jeroen@liver:~/Projects/Wunderkraut/VOK_digit$ uname -a
Darwin liver.local 17.0.0 Darwin Kernel Version 17.0.0: Thu Aug 24 22:01:05 PDT 2017; root:xnu-4570.1.46~3/RELEASE_X86_64 x86_64
jeroen@liver:~/Projects/Wunderkraut/VOK_digit$ cat /etc/exports | grep digit/www.*50.2
"/Users/jeroen/Projects/Wunderkraut/VOK_digit/www" 192.168.50.2 -alldirs -mapall=501:20
jeroen@liver:~/Projects/Wunderkraut/VOK_digit$ vagrant ssh

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sat Sep 2 11:04:22 2017 from 10.0.2.2
vagrant@vagrant:~$ cat /etc/fstab | grep www
192.168.50.1:/Users/jeroen/Projects/Wunderkraut/VOK_digit/www /var/www nfs defaults,sync 0 0
vagrant@vagrant:~$ sudo ifconfig | grep inet | grep 50.2
inet addr:192.168.50.2 Bcast:192.168.50.255 Mask:255.255.255.0
vagrant@vagrant:~$ cd /var/www
vagrant@vagrant:/var/www$ mkdir test && cd test
vagrant@vagrant:/var/www/test$ touch test{1..1000}
vagrant@vagrant:/var/www/test$ ls | wc -l
1007
vagrant@vagrant:/var/www/test$ ls | uniq -c | grep " 2"
2 test136
2 test137
2 test472
2 test689
2 test7
2 test723
2 test853
2 test96
vagrant@vagrant:/var/www/test$ exit
logout
Connection to 127.0.0.1 closed.
jeroen@liver:~/Projects/Wunderkraut/VOK_digit$ cd www/test/ && ls | wc -l
1000
jeroen@liver:~/Projects/Wunderkraut/VOK_digit/www/test$ ```

[kylebrowning]

@kikitux we cant re-open High Sierra is coming soon.

[briancain]

I've reopened the issue @kylebrowning @Yaroon

[briancain]

@kylebrowning or @Yaroon ...if you could confirm, does this behavior happen if you run the mount command yourself outside of Vagrant? If that's the case then it is probably a bug with NFS on High Sierra. It'd be something like....

mount -o vers=3,udp <ip address of machine>:/Local/Path/to/Vagrant /Remote/Path/To/vagrant

[Yaroon]

@briancain I had indeed already booted the guest OS in just VirtualBox with NFS set up in its /etc/fstab. But just for you I unmounted /var/www on the guest and tried it with:

sudo mount -o vers=3,udp 192.168.50.1:/Path/to/Vagrant/www /var/www

No change. When I create 1000 files in a folder and count them with ls | wc -l it prints 1038 instead of 1000.

[briancain]

OK thanks @Yaroon . I assume you mean that there's 1000 files on your host, and on the supposed NFS mounted directory on the guest there are 1038 files?

[Yaroon]

That is correct.

[briancain]

Hmm alright, that's too bad :( I think in that case there isn't much we can do about it, if it's a bug with macOS. That would be the same command vagrant would run when mounting folders with NFS.

[Yaroon]

I filed a bug with Apple weeks ago, but it hasn't been looked at yet. At least it hasn't been marked as duplicate...

It's funny that I'm seeing so little about it online. Isn't anyone using macOS High Sierra? A lot of (web)development these days happens in Vagrant/Docker with NFS folders mounted... surely 1000s of devs must be seeing this. But nope. I think next week when macOS High Sierra is released you'll see many suddenly complain :)

[benjifisher]

Workaround

According to the comments in geerlingguy/drupal-vm/issues/1547, this is an issue with APFS. You still have the option of creating a partition formatted as HFS+ (identified as "Max OS Extended (Journaled)" in Apple's Disk Utility) and working from there, even if you want to keep using APFS for your primary partition.

[fractalzombie]

Have this issue too with newely released high sierra

[BrianGilbert]

I reported this to Apple from beta 2 or 3 of High Sierra: https://github.com/hashicorp/vagrant/issues/8957#issuecomment-332175947

[svpernova09]

Is this issue isolated to NFS?

[BrianGilbert]

@svpernova09 Thats the only place I've seen issues so far.

[navneet0693]

I did faced this problem when I tried macOS High Sierra beta. Changing vagrant synced folder type to rsync is what worked for me alongwith vagrant-gatling-rsync plugin. Here is a small write up of how-to about the same:

https://goo.gl/73WKrn

[blopker]

To save you a click the solution @navneet0693 posted is to use rsync.

[blopker]

For what it's worth, using VMWare's shared folders works fine, but is much slower than NFS. Maybe 2-3x slower. We have a large codebase so it's noticeable.

Should the needs-repro tag be taken off this issue?

[chrisroberts]

@blopker Just a note, the needs-repro tag is simply a note for us that we need to reproduce the issue on our end to fully diagnose the problem. :smiley:

[trappar]

Had this issue as well. I created an HFS formatted sparsebundle blank image using Disk Utility and put my project in there as a way to avoid the problem. The performance seems comparable to how the project ran previously. Feels like this shouldn’t be necessary...

[blopker]

Thank you for the clarification @chrisroberts. I can reproduce pretty easily, just newest Vagrant on High Sierra with an NFS mount. Although to be fair I don't know if this can be fixed in Vagrant, but this is a nice place to track the issue.

[danmurf]

@trappar I've just tried this and I'm still unable to mount the NFS shared folder. Are you also storing the Virtual Box .box file on the sparse bundle disk image? I've just got my project source checked out to the disk image, which is also where my Vagrantfile is, then I'm running vagrant up from the disk image. Any idea why this might be happening still?

[trappar]

Yeah, I moved my entire project and all files into the sparsebundle, so the VM is running inside it as well. You might have to recreate your VM? I didn’t, but I’m using a different provider, and I’m not sure if VirtualBox is okay with a .vagrant folder being moved.

[mfn]

I did not touch the .box file. I moved my host folder importantProject/ onto the Sparse set and recreated the (destroy, up) the VM and that did it for me.

[danmurf]

I've just tried moving my default Virtual Box machine folder to the disk image, destory and up (so the machine is created on the disk image) but it's still having the same problem. Both my source files, and the Virtual Box machine, are stored on the disk image now. The disk image is Mac OS Extended (Journaled), and stored and mounted from my home folder.

[kjanoudi]

@danmurf what i did was create a new sparsebundle image using disk utility, mount it, copy all my code folders into that volume, and vagrant up from the mounted image. I did not destroy my machine, and i did not move the folder that contains the Vagrantfile. I only moved the folders that i had set to sync via NFS.

Old:

/me/project folder with .vagrant, Vagrantfile, and all vagrant related configs. Also in this folder was my syncd NFS folders: /me/project/code sync'd to /home/vagrant/code

New:

/me/project folder with .vagrant, Vagrantfile, and all vagrant related configs. Now in this folder, a code.sparsebundle image. I mount this image, and changed my Vagrantfile sync to: /Volumes/code sync'd to /home/vagrant/code.

[Yaroon]

For what it's worth, the bug I had filed with Apple [ 34127784 ] has yesterday been marked as a duplicate of 34718050 and will be closed. So someone at Apple is actively aware of the issue.

[matusch]

@Yaroon could you share a link to the ticket?

[Yaroon]

I didn't provide links because you can't really access Apple bugreports anyway, but here they are:

Mine: https://bugreport.apple.com/web/?problemID=34127784
Other: https://bugreport.apple.com/web/?problemID=34718050

[chrisroberts]

I have been digging for any configuration that may allow for correct behavior of nfsd on High Sierra but have so far been unsuccessful. After digging into past linux NFS issues, similar problems have been seen before:

https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/921403
https://bugzilla.redhat.com/show_bug.cgi?id=739222

I can easily and reliably reproduce the error state. I found that disabling readdirplus on the NFS client helped to reduce the number of duplicate files shown, yet I still end up with one "duplicate" file on the guest and one file on the host that is not visible on the guest. As of now it doesn't look like there is anything that will be effective to make things work correctly until a fix from Apple is shipped. Updated tickets is a good sign, and the more bug reports that are submitted should help make the problem more visible and hopefully expedite a fix.

Even though this is a third-party issue, I'll leave this issue open until a fix has been released.

[altryne]

Just came to say that upgraded to 10.13.1 beta release and the NFS issue is still here

[mikolazp]

I have two mounted folders in project, first one have this issue with files (I don't see some files) but another one works fine.
They are mounted with different nfs options
First one with problem:
config.vm.synced_folder "./data/mysql", "/var/lib/mysql", type: "nfs"
Second one without problem:
config.vm.synced_folder "./data/mysql", "/var/lib/mysql", type: "nfs", mount_options: ['rw', 'vers=3', 'tcp', 'fsc' ,'actimeo=1']

I've added these additional mount options for another folders and they start works fine.
I don't know, maybe that accidental coincidence, but they are works fine now.

[micronax]

I can confirm, this works at least better than without the additional options. I get no more missing files and the sync also seems to work reliable. I keep you updated.

[oekaraduman]

This works for me too. Great work @mikolazp

[sergentrif]

The solution of @mikolazp worked for me too.

[pascaldevink]

As mentioned in https://github.com/hashicorp/vagrant/issues/8957#issuecomment-331825857, it's probably the tcp option that makes it "work". Although there is still no guarantee that all files are synced, it seems to work good enough for a lot of people to be a viable workaround.

Be warned though: it still doesn't sync 100%.

[mikolazp]

Seems like that not full solution of issue.

I've noticed, that if i try test from this place https://github.com/hashicorp/vagrant/issues/8957
I also have the same problem:
mkdir test && cd test && touch test{1..1000} && ls | wc -l
Result is 1007, but should be 1000. And also I can't remove folder "test" inside virtual machine.

I can't live with that :)
I decide to roll back on Sierra 10.12.6

[Shura80]

It works for me too, thank you @mikolazp !

[gideoncresswell]

tcp did not work for me (it was already set as that.) I've had to resort to using rsync to get it to work for now. Although it's only a one-way sync. If I upload files to the vagrant instance (it's a DrupalVM) they won't show up on my Mac folder - only inside the vm.

[fredsted]

FWIW, I switched to using VirtualBox's default folder sync which seems to work, but is a good deal slower.

[fractalzombie]

Check with this options:
[ 'nolock', 'vers=3', 'tcp', 'fsc', 'rw', 'noatime' ]

[pySilver]

@fractalzombie works fine!

[altryne]

@fractalzombie I'm getitng this error :
```[ 'nolock', 'vers=3', 'tcp', 'fsc', 'rw', 'noatime' ]
mount -t vboxsf -o nolock,vers=3,tcp,fsc,rw,noatime,uid=1000,gid=1000 logs_ /opt/logs

The error output from the command was:

unknown mount option `noatime'
```

And my vbox additions are up to date, any advice?

[mfn]

FTR I tried https://github.com/hashicorp/vagrant/issues/8788#issuecomment-334167897 but still saw duplicate files.

[froboy]

I had success removing the hfs declaration altogether and reverting to the "default" sync behavior, so
config.vm.synced_folder "./data/mysql", "/var/lib/mysql", type: "nfs"
would become
config.vm.synced_folder "./data/mysql", "/var/lib/mysql"

Then just vagrant reload --provision or vagrant halt && vagrant up --provision

[altryne]

@froboy depending on your needs, NFS offers a very big performance boost. The default syncing is slow a lot of times, and is not fast enough for people to work with.

[cuky23]

we upgraded two Macs this week to lastest release, they saw issues that caused NFS to fail.
double entry of file appear on the guest os.

Has a workaround been found yet? I dont think this is vagrant at fault, this looks like VB and MAC nfs not working together again

[kylebrowning]

This is how I did it.

https://github.com/geerlingguy/drupal-vm/issues/1547#issuecomment-330572626

[benjifisher]

@kylebrowning That is the same method I summarized above with the heading "Workaround". Maybe someone with enough permissions on this project could update the first comment since there are at least 3 approaches that seem to work around the bug:

• Create an HFS partition https://github.com/geerlingguy/drupal-vm/issues/1547#issuecomment-330572626
• Tweak your nfs options: https://github.com/hashicorp/vagrant/issues/8788#issuecomment-334167897
• Give up on nfs and use native vagrant file sharing or rsync

... and they get missed because there are so many other comments on this issue.

[narration-sd]

@snfnwgi You can have a look at @benjifisher comment here, just above -- nicely lists solutions knkown at present for the underlying MacOs nfs problems.

Rsync is only one -- maybe another will help your situation?

They look simple to try --- more simple than rsync, surely.

[oleyur]

I had same issue with NFS mounting on High Sierra. I did backup of Hight Sierra system, erased hard drive with formatting to Mac OS Extended (Journaled) file system. After that I have restored backup to it and I have now old file system. Works fine as earlier.

[b-long]

Sorry for the noise, but I have a stupid question -- this issue is relevant for macOS Sierra (10.12) too. Correct?

[benjifisher]

@b-long I am using Sierra, and I have not noticed this problem. I see that #8061 links here, so maybe that will help you.

[jorisnoo]

@b-long This issue is related to hard drives formatted in the APFS file
system, which was introduced with High Sierra.
On Thu, 5 Oct 2017 at 19:23, Benji Fisher [e-mail] wrote:

@b-long https://github.com/b-long I am using Sierra, and I have not
noticed this problem. I see that #8061
https://github.com/hashicorp/vagrant/issues/8061 links here, so maybe
that will help you.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/vagrant/issues/8788#issuecomment-334533794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFiqVKuFvQGdrbofKXuOX9YPdrwrby37ks5spRB_gaJpZM4OZYSw
.

[chrisroberts]

As noted here, the issue is not isolated to _just_ APFS formatted partitions on High Sierra.

[danmurf]

Just noticed there's a 10.13 supplemental update:

https://support.apple.com/en-gb/HT208165

Anyone tried it yet in relation to this issue? Looks like it might just be fixing security issues.

[ctrlrsf]

My issue was fixed with these options: ['nolock', 'vers=3', 'tcp', 'fsc', 'rw', 'noatime']. Thanks @fractalzombie

[fractalzombie]

I think problem in nanotime of APFS...

[leandroalemao]

@froboy suggestion worked here! All good now! Tks! 👍 😄

[daniel-chris-lucas]

@danmurf I updated using the supplemental update this morning and NFS seems to work correctly for me now

[ghost]

@daniel-chris-lucas

There are still duplicated files after the supplemental update.

[dimianstudio]

yes nothing changed still duplicated files

[chrisroberts]

Trying the mount options: ['nolock', 'vers=3', 'tcp', 'fsc', 'rw', 'noatime'] with High Sierra still resulted in duplicates:

host$ ls /usr/lib | wc -l
308

guest$ ls /vagrant-nfs | wc -l
312

And I am still seeing the same behavior after the update.

[dubelaar]

Having the same issue with vagrant NFS share after upgrading to Sierra high, also the supplemental update did not solve the issue.

[dvdcastro]

There was a temporary workaround found in http://www.qed42.com/blog/macos-sierra-issues-vagrant while NFS becomes available again

[danmurf]

Mine still isn't working following the latest supplemental update. I applied the fix (using rsync, as mentioned above in @dvdcastro's link) and this seems to get it working again, albeit a lot slower.

[AlekseyKorzun]

The rsync and non-NFS based synchronization is not a viable solution for heavy users with thousands of files.

I can confirm that the disk image approach works. Far from ideal.. but works.

Don't forget to:

• Open the Disk Utility
• File -> New Image -> New Blank Image
• Specify name, size, format as (Mac OS Extended (Journaled)
• Save
• Halt your VM
• Move checkout (containing Vagrantfile) to newly created image (/Volumes/__NAME__)
• Clean /etc/exports (sudo nano -w /etc/exports)
• Run sudo nfsd restart
• Change path(s) in .vagrant/machines/default/virtualbox/synced_folders
• Vagrant reload from the moved checkout directory on the image

[Yaroon]

For the record, macOS High Sierra 10.13.1 Public Beta 2 (17B35a) does not fix the issue.

[frankvanhest]

The latest update for MacOS seemed to have solved the problem, but after a short while it came back.
For now I just use the workaround given by @AlekseyKorzun. At least I can continue working.

[felipecabargas]

I just removed nfs:true from my Vagrantfile. No rsync or anything and it started working again. Obviously this is a workaround while NFS support becomes stable again.

This was under both: 10.13.1 Beta (17B35a) and 10.13 Beta (17A362a)

[gideoncresswell]

Rsync is too slow for me and also I need syncing to work both ways. So I have switched to @AlekseyKorzun's workaround about 3 comments above. This works for me - although not ideal! One thing I noticed, you can't have a space character in your disk image name or you will get a command-line line 0: garbage at end of line; error when using vagrant commands from a shell.

[haco28]

as @dvdcastro says:
http://www.qed42.com/blog/macos-sierra-issues-vagrant this solution works for me
instead of use NFS we have to use (temporarly) RSYNC way.
Hope it will help all

[trappar]

I think it would be helpful if people stopped suggesting solutions that involve removing/changing “:nfs”. These solutions don’t solve the problem, they just avoid it at the cost of performance/functionality.

Currently the sparse bundle method is the only actual solution I’ve seen. It’s still avoiding the problems with APFS but it maintains the same performance/functionality.

[haco28]

what about this : http://www.techrepublic.com/article/how-to-revert-back-to-apples-hfs-from-apfs/ ? i don't know the risk about this operation

[eelkeblok]

I would personally not recommend this. In terms of underlying architecture APFS is vastly superior and your data is much better off being on it than on HFS. Also, see @trappar's comment above (he mentions switching away from nfs being a workaround. I would argue the exact same reasoning applies to switching away from APFS; it is avoiding the problem, not solving it). We can add this to the ever growing list of workarounds, I suppose.

I personally think the rsync-variant is probably the best workaround, because it leaves your project files right where they are and it doesn't involve crippling your regular work volume . The only big downside is that setting it up may involve a long wait as the files synchronise, if you have a lot of files.

Edit: Having actually tried this now I must say there is at least one other downside, which is that rsync only syncs one way, so if your workflow involves generating files from the development machine that need to be checked into version control (e.g. Features or configuration export in the case of Drupal) this will not work for you. In addition, I couldn't get auto syncing to work properly, but that might be a problem with my setup.

[thieman]

APFS is vastly superior

As long as you don't care about NFS support, clearly.

crippling your regular work volume

This is total FUD, we've all been using HFS+ for decades and staying on it for a few more months to let Apple figure out some showstopping bugs is not the end of the world.

If you're in a situation where you've already upgraded to High Sierra, the HFS+ path should give you the same NFS performance you're used to and you should be able to switch back to APFS once it's ready.

[eelkeblok]

This is total FUD

Thanks. You’re entitled to your opinion, please let me have mine. Maybe the choice of words is a little dramatic, I’ll give you that. Converting from one file system to another is a risky undertaking, simple as that.

[kylebrowning]

Not sure why you would want to convert you're entire hard drive back to HFS when you can just use a sparsebundle.

But to each their own.

[sgarbesi]

@ctrlrsf Thank you! Solved the problem for me.

The problem for me was a file wasn't showing up in a directory, even though if I directly attempted to cat the file the contents would display fine in console.

[dimianstudio]

Yeah sparsebundle that's what I need for now. Works great!

[coffe4u]

OP had:

config.vm.synced_folder "www", "/var/www", type: "nfs" 
config.vm.synced_folder "db", "/home/vagrant/db", :nfs => true
config.vm.synced_folder "scripts", "/home/vagrant/scripts", :nfs => { :mount_options => ["mfsymlinks"] }

I think it should be:

config.vm.synced_folder "www", "/var/www", type: "nfs" 
config.vm.synced_folder "db", "/home/vagrant/db", nfs: true
config.vm.synced_folder "scripts", "/home/vagrant/scripts", nfs: {mount_options: ["mfsymlinks"] }

[lightster]

(@coffe4u As a Ruby newb myself, I believe those are equivalent. The latter is newer Ruby syntactic sugar. 🍬 )

[thieman]

It looks like there's a new High Sierra beta out today, if anyone following this thread is available to test it

[Yaroon]

@thieman: macOS High Sierra 10.13.1 Beta (17B42a) does not fix the issue.

[flyer103]

It doesn't work for solving duplicating files described in https://github.com/hashicorp/vagrant/issues/9068 by setting ['nolock', 'vers=3', 'tcp', 'fsc', 'actimeo=1', 'rw'] for nfs.
And if there are too many files, for example 465014, using rsync will fail 😞

[ngdot]

Hi guys, got the same problem on my machine, but I finally solved it with a "small" workaround.
I resized my AFPS partition and created a second HFS+ partition and moved my vm folder onto.
Here you can find a tutorial for the command line. If you got problems with resizing your partition make sure to delete all your localsnapshots from timemachine, see this post.

I hope it helps!

[jesusabarca]

The rsync solution was too slow for me. One devops from work suggested sshfs, so I tried it and seems to be working good 👍

Here's a plugin for vagrant https://github.com/dustymabe/vagrant-sshfs. In my case, I had to add the nonempty option like:

config.vm.synced_folder '/local/path', '/target/path/in/vm', type: 'sshfs', sshfs_opts_append: '-o nonempty'

[Yaroon]

macOS High Sierra 10.13.1 Beta (17B45a) does not fix the issue.

[maksimovic]

Depending on how large/complex your project is, sshfs may be too slow as well. In my case, average response for a LAMP application is slower around 20 times (compared to hfs) 😶

[woutersamaey]

@maksimovic how do you benchmark? I switched to Parallels Desktop for Mac with Shared Folders instead of NFS and find the performance "quite good", but haven't run any benchmarks.

It also feels faster than Virtualbox in general ("vagrant up" command for example).

[maksimovic]

@woutersamaey It's quite obvious because all requests are terribly slow. For example, dashboard page loads in <1s when hfs is used, while with sshfs it can't go under 20s (opcached, otherwise it's 30s+). Just bootstrapping the application takes 2-3s with sshfs, so regular day-to-day work is pretty impossible.

[woutersamaey]

@maksimovic, I think you should switch to Parallels with Shared Folders if that's an option. For Magento 2 development (lots of files, huge, complex PHP site) the performance is good.

[tobiasvielmetter]

@woutersamaey I dont have scientific performance comparisons, but switching to parallels was a 1 hour detour for me, that certainly didn't deliver better performance. After this I cannot recommend using parallels for this purpose.

[woutersamaey]

I’m sorry @tobiasvielmetter that it didn’t work out for you, but my experience has been great so far and continuing to be so.

[kylebrowning]

Sparse image bundle works 100% the same way it did pre APFS. I’m not sure why y’all are trying different things.

On Oct 27, 2017, at 1:45 PM, Wouter Samaey [e-mail] wrote:

I’m sorry @tobiasvielmetter that it didn’t work out for you, but my experience has been great so far and continuing to be so.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[tobiasvielmetter]

@kylebrowning Thanks, I had trouble creating the proper image, but was now successful and it works. Gulp is a bit slower on the host machine through the sparse-image, but overall it seems to work fine and a bit faster, so thanks for pointing that out again. Reformatting with a HFS partition seemed a little risky, so the sparse image approach is great!
If someone else has trouble with creating the image, here are the settings i used successfully in disk utility:

[danielvonmitschke]

@tobiasvielmetter what you created is NOT a sparseimage/bundle.
It's just a regular image/DMG.
The advantage of a sparseimage/bundle is that it only uses so much space as it currently needs on your disk. A regular image will always occupy all the space it got allocated.

[tobiasvielmetter]

@danielvonmitschke sorry, I selected the wrong thing for the screenshot. thanks for pointing it out. it needs to be a sparsbundle (or image), as far as i understand bundle is better for backup support. Thanks for pointing it out.

[danielvonmitschke]

@tobiasvielmetter I tried to install a fresh vagrant vm in a sparse image and it did not work.

[tobiasvielmetter]

@danielvonmitschke You don't install the vagrant vm inside of the sparse bundle / image. You just use the spars bundle as a location for your code to be synchronised via nfs with your vm. The vm is installed on your apfs system.

[scottsb]

If you want a shortcut to creating and managing a sparse bundle, see this bash script. It's described in terms of managing a case sensitive filesystem but would serve this NFS workaround purpose too: https://gist.github.com/scottsb/479bebe8b4b86bf17e2d

One caveat to the sparse bundle approach: at least in older versions the macOS kernel could sometimes run away in terms of CPU & memory usage when there was heavy file access of the bundle. If you have overheard to spare that may not be an issue, but if you're tight it probably will.

[ghost]

~Seems to be fixed with todays update...~
~Anyone else can confirm?~

Nevermind, mistake was on my side. Sorry!

[mkleucker]

Can't confirm. Still broken with 10.13.1 for me. Anyone running the 10.13.2 beta?

On the host system

> touch test{1..1000}                                                                                                                           
> ls | wc -l
1000

In the Vagrantbox

> ls | wc -l
1038

[Yaroon]

@mkleucker: @EvulMastah is talking about the 10.13.2 beta indeed, not about 10.13.1

[josezenem]

Tested using 10.13.2 Beta (17C60c) as of Oct 31, 2017 3:49pm PST everything seems to be working without any issues. I will keep testing and update if I see any issues.

[josezenem]

An update on 10.13.2 Beta (17C60c) for everyone, everything is still working.

ran in host system:

$ find . -type f | wc -l
231752

ran in vagrant:

$ find . -type f | wc -l
 231752

The downside so far is that currently the OS as a whole is not as snappy, and has crashed at least once (I expected this due to it being a beta). Hopefully at some point someone else can confirm the folder issue being resolved. For now I will keep testing, and report back with any findings.

[elvis2]

Just wanted to let others know, the 10.13.1 build has fixed my NFS issues with DrupalVM. I am running on Vagrant 2.0.0.

[BrianGilbert]

@elvis2 Are you sure you don't mean 10.13.2?
I can confirm NFS issue with APFS volumes is fixed as of 10.13.2 Beta (17C60c)

[elvis2]

@BrianGilbert I am referring to 10.13.1. I did minor testing, so far my tests are good. I will run a few more tests and report back.

[BrianGilbert]

@elvis2 double check you've converted drive to APFS, as I've seen multiple confirmations it wasn't working previously and confirmed myself with the update mentioned in my post above..

[bokorir]

10.13.1 was still bad for me. Installed 10.13.2 Beta 1 solved the problem.

[elvis2]

@BrianGilbert Yes, you are correct. I retract my statement.

After blowing away directories and having composer rebuild them (from the host machine), I do see a handful of files don't get moved to the guest. Moving on to 10.13.2 Beta...

[zored]

Could someone explain why some flags (from rw,vers=3,tcp,fsc,actimeo=1) for NFS should fix that problem? They are not directly related to this problem. 😃

[jfbibeau]

@zored I don't believe there's any evidence those flags fix the problem.

[BrianGilbert]

This issue is resolved as of 10.13.2 beta

[tlshaheen]

@jesusabarca's answer (https://github.com/hashicorp/vagrant/issues/8788#issuecomment-338348853) worked for me as a temp fix since I don't have access to the 10.13.2 developer beta.

I'm using Laravel Homestead, and I edited my Homestead.yaml to be:
folders: - map: /my/local/folder to: /my/vagrant/folder type: "sshfs" options: sshfs_opts_append: "-o nonempty"

I then deleted my vendor folder and re-ran composer install. All good now. Will go back to NFS after I get 10.13.2!

[marinovdf]

Guys, what do you see with 10.13.2 beta? With 10.13.1 I have:

...
drwxrwxr-x  34  501 dialout    1088 Nov  2 08:55 vendor/
drwxrwxr-x  34  501 dialout    1088 Nov  2 08:55 vendor/
drwxrwxr-x  34  501 dialout    1088 Nov  2 08:55 vendor/
...

Problem with 501 dialout also fixed?
Thanks.

[scottsb]

@marinovdf That's not actually a bug. That's just the way NFS works: it's mapping the owner and group IDs from macOS to the names on the guest OS. If it causes issues you can look into this plugin, which uses FUSE to remap the NFS share with locally correct ownership, albeit at a performance cost: https://github.com/gael-ian/vagrant-bindfs

[marinovdf]

@scottsb Thanks!

[andredewaard]

Can confirm this is fixed under High Sierra 10.13.2 Beta 1 with Laravel Homestead.

[klevie]

For me, this problem was not solved by upgrading to High Sierra 10.13.2 Beta 1 or Beta 2.

However, I tried several NFS mount options mentioned in this issue and there is one that (by itself) makes a huge difference for the better: actimeo=1

[jayd3e]

Can confirm that this problem has been solved in High Sierra 10.13.2 Beta 2. You can signed up for it here. From there, you will be able to download Beta 2.

[scottsb]

Those who've upgraded to Beta 2: are you seeing #8061 fixed as well?

[jfbibeau]

@scottsb Upgrading to High Sierra 10.13.2 Beta 2 right now, I'll verify this one and #8061 as well! Keep you posted.

[jfbibeau]

Running 10.13.2 Beta 2 (17C67b) and this definitely appears fixed.

[vagrant@nsp-latest nfs]$ while true; do touch test{1..1000} && ls | wc -l && rm *; sleep 1; done
1000
1000
1000
1000
1000
1000
1000

My mount options, for what its worth (options haven't changed between MacOS releases):

override.vm.synced_folder "../../", "/workspace",
        :nfs => true,
        :mount_options => ['actimeo=2'],
        :linux__nfs_options => ['rw','no_subtree_check','all_squash','async']

[eveyrat]

Upgrading to Mac OS High Sierra 10.13.2 Developer beta fixes the problem

[ev0rtex]

I upgraded to 10.13.2 beta 2 over the weekend and I've been testing a bunch the last couple days. This does indeed seem to be solved with the upgrade for me. I think that once 10.13.2 is released officially we will finally be able to close this.

[chrisfromredfin]

I have been running on the beta for over a week and do believe that both #8788 (this one) and #8061 appear fixed. In fact, High Sierra at all fixed #8061, but introduced this one. But both are seemingly not a problem in 10.13.2.

[placid2000]

Thanks for reporting. This are great news. Does anybody know when the stable version is going to be released?

[ghost]

@placid2000

https://robservatory.com/a-useless-analysis-of-os-x-release-dates/

I would expect it by the end of this month/beginning of next.

[polarbirke]

I can confirm that the current Beta 4 of 10.13.2 fixes this issue.

[rakauchuk]

Hmm.. strange situation, but I got this issue on High Sierra and APFS w/ NFS sharing. Just solved it w/ that https://github.com/hashicorp/vagrant/issues/8788#issuecomment-338348853

[emileber]

EDIT: This is already fixed, see the next comment.
Be careful with High Sierra as there is a major security breach right now: https://www.macrumors.com/2017/11/28/macos-high-sierra-bug-admin-access/

[Didel]

The security breach mentioned above is already fixed by Apple with an update that can be installed through the Updates tab of the MacOS App Store.
https://www.macrumors.com/2017/11/29/apple-fixes-root-password-bug-security-update/

[uniacid]

Can confirm I was having this issue as well, Beta 4 of OSX 10.13.2 fixed this issue, now on Beta 5 though, also Vagrant 1.9.5 here.

[kylebrowning]

That’s because it’s unrelated.

[jfbibeau]

Since this thread is starting to get derailed and we know the issue's fixed, should we go ahead and close it?

[svpernova09]

Yep should be safe to close.

--

• Joe Ferguson
  JoeFerguson.me
  MemphisPHP.org

On Nov 29, 2017, 21:31 -0600, JF Bibeau [e-mail], wrote:

Since this thread is starting to get derailed and we know the issue's fixed, should we go ahead and close it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[benjifisher]

Let's leave it open until 10.13.2 is released. Closed issues are less visible, and I bet that there are still people looking for this information.

[deiga]

Locking the issue could be a good idea

[josadeluca]

FWIW, the issue does seem to be fixed on my CentOS 7 VM, but I still have a CentOS 6 (32 bit) VM on which it most definitely is not fixed (with 10.13.2 Beta 5). All the same symptoms persist. The mounts on that VM only work when using sshfs.

[ApacheEx]

Finally, 10.13.2 is released. 🎉
https://support.apple.com/en-us/HT208179

[martell]

Can we now close this issue :)
Was waiting for that release for too long.

[rogierslag]

I can confirm that the final version also solves the issue

[jandubois]

After all the positive feedback here I decided to try 10.13.2 too, without the intermediate sparsebundle. Unfortunately it doesn't even mount anymore for me:

vagrant-kube:/home/vagrant # mount -o vers=3,udp 192.168.77.1:/Users/jan/suse/scf /home/vagrant/scf
mount.nfs: access denied by server while mounting 192.168.77.1:/Users/jan/suse/scf

(the same error happens during vagrant up, but I can repro it manually after vagrant ssh as well).

I forgot to test directly after installing the 10.13.2 upgrade, so I don't know if it is related to the upgrade, or somehow cause by removing the sparsebundle.

/etc/exports looks fine to me:

$ cat /etc/exports
# VAGRANT-BEGIN: 501 9b1e50a6-bae8-4e32-9a38-81557fcf4c7a
"/Users/jan/suse/scf" "/Users/jan/suse/scf/.fissile/.bosh" 192.168.77.77 -alldirs -mapall=501:20
# VAGRANT-END: 501 9b1e50a6-bae8-4e32-9a38-81557fcf4c7a

Any ideas?

[emileber]

@jandubois you should open a new issue as it looks unrelated to this issue.

[briancain]

@jandubois yeah...like @emileber just said that seems like a separate issue from this one. I recommend opening a new issue here on Github with all the information from the template filled out. Thanks!

[jandubois]

you should open a new issue as it looks unrelated to this issue.

Agreed. I'll first look into this some more myself though; I have another machine that I will upgrade to 10.13.2 tomorrow and will look more carefully after each step to see when/if that one will break in the same way.

[jfbibeau]

I've just updated from the Beta to the release load of 10.13.2 and everything is good to go. NFS mount works perfectly.

[lazaronixon]

Solved here too..

[sweh]

I have the same issue as @jandubois. If I unmount the SparseBundle and put my files directly into the folder where the Bundle was mounted, vagrant is not able to mount that folder into the VM. Switching back to the SparseBundle works fine.

[janssensjelle]

works for me now 👍

[dnl-jst]

@sweh @jandubois Did you move the project without destroying and recreating the box? I had the same issue, vagrant seems to save the project path, and if you move the project, the paths changes, but vagrant tries to mount the old path. All I did was destroying and recreating the box after moving. Didn't do more research if the path can be fixed without destroying the box.

[sweh]

No, I did not move anything. The path to the mounted SparseBundle and the folder in the AFS filesystem respectively are the same.

[BR0kEN-]

@dnl-jst, you can manually edit the ~/.vagrant.d/data/machine-index/index.

You'll have the ~/.vagrant.d part only if https://www.vagrantup.com/docs/other/environmental-variables.html#vagrant_home is not set or has exactly the same value.

[rakauchuk]

10.13.2 solved the problem for me.

[trappar]

Yeah, it would appear that 10.13.2 solves this, but is it just me.. or is it a little slower than NFS on an HFS+ formatted drive/sparsebundle?

[ireznik]

I upgraded directly to 10.13.2. Everything works as expected, no issues so far with nfs usage in vagrant for my vm!

[shamimmirzai]

@trappar its much slower I agree. And I find when I save a file on the Mac side, within vagrant the file is missing for quite a few seconds before it shows up again with the up to date content. Definitely much slower than it used to be on HFS+

[Oscarteg]

@trappar @shamdsc I'm having the same issue. It's much slower. Takes couple of seconds for it to sync properly. Is this a Vagrant issue or an Apple issue?

[emileber]

@Oscarteg @shamdsc @trappar Please open a new issue since this one is about _folders not properly synced_ and looks to be resolved, it's not about syncing speeds. Additional issues should be taken care of individually in their own thread.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.