Use host_inodes flag when mounting shared folders

[MalteWunsch]

After updating to Parallels 16 and the corresponding Parallels Tools in the guest VM, we experienced the following problem with the install command in shared folders with the prl_fs:

$ install foo bar
install: skipping file 'foo', as it was replaced while being copied

This seems to be same issue as described in https://forum.parallels.com/threads/cannot-move-file-in-shared-folder-after-upgrade-to-pd16.350648/ , at least we were able to solve it by passing the host_inodes flag as a mount option in our Vagrantfile:

-  config.vm.synced_folder "~/Projekte", "/var/www", mount_options: ["share", "noatime"]
+  config.vm.synced_folder "~/Projekte", "/var/www", mount_options: ["share", "noatime", "host_inodes"]

This PR suggests to make this a default mount option.

/cc @mpdude

[MalteWunsch]

Probably fixes #361 .

[lenineto]

Dude, I owe you a beer! I've been banging my head against the wall with this issue on a vvv and that worked beautifully. I hope the Parallels team will merge your commit so we have a working plugin anytime soon.

Thanks! And I'm serious about that beer.

[legal90]

@romankulikov Could you please have a look at this? Should we use host_inodes option by default only on PD 16, or it could be used also on earlier versions? Will it work with outdated Parallels Tools (let's say PT v13. with PD host v16.) ?

[mpdude]

Caveat: As I understand it, when there are sub-filesystems mounted in the host below a shared folder, host_inodes won’t work (?).

But the other way round, without it many commands (cp, install,...) that check inodes and/or do fstat() stuff don’t work.

[getsource]

Yes, thanks so much!

This fixed the problem for me in VVV as well.

[lenineto]

Caveat: As I understand it, when there are sub-filesystems mounted in the host below a shared folder, host_inodes won’t work (?).

But the other way round, without it many commands (cp, install,...) that check inodes and/or do fstat() stuff don’t work.

Perhaps accept "host_inodes" as a parameter we can pass to mount_options: [] on the Vagrantfile? Not ideal of course, but a better way to handle it for now until you can reach a universal solution.

[mpdude]

@lenineto you can pass that as a mount option without changes required in the plugin.

The point is that you have to know about it, and that upgrading to Parallels 16 might break things in your VM if you don’t update the Vagrantfile.

[lenineto]

I tried passing it as an argument, doesn't work.

On Sat, 12 Sep 2020, 12:40 Matthias Pigulla, notifications@github.com wrote:

@lenineto https://github.com/lenineto you can pass that as a mount option without changes required in the plugin.

The point is that you have to know about it, and that upgrading to Parallels 16 might break things in your VM if you don’t update the Vagrantfile.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Parallels/vagrant-parallels/pull/362#issuecomment-691475071, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFJGP3PGBSWDNOOLVGNXTDSFNM2XANCNFSM4Q56SR4A .

[mpdude]

See the initial comment – that’s taken from a Vagrantfile that works...

[lenineto]

See the initial comment – that’s taken from a Vagrantfile that works...

I see that, but my point is, when I put that on the Vagrant file, WITHOUT MalteWunch's patch, it does nothing.

You can see on his patched file 'lib/vagrant-parallels/guest_cap/linux/mount_parallels_shared_folder.rb', the code

# First mount command uses getent to get the group
mount_options = "-o uid=#{mount_uid},gid=#{mount_gid},host_inodes"

Without the patch, using the "host_inodes" on the Vagrant file is of no effect.

[getsource]

@lenineto

Without the patch, using the "host_inodes" on the Vagrant file is of no effect.

This is not my experience. It might be worthwhile to double-check that there aren't any mounts missing host_inodes in the Vagrantfile.

You mentioned VVV -- for that, it means replacing the the Parallels exceptions for each of the folders (or at least, that's how I did it) to include it. It's quite likely that there is a simpler way, but here's a diff of mine that is working, in case it helps.

My understanding of this PR is that it changes what the defaults are, so specifying it in a Vagrantfile like in the diff above or the example in the ticket should work, like @mpdude mentioned.

[mpdude]

👆🏻👍🏻

[legal90]

I spent a bit more time on reproducing the issue on different versions of Parallels Desktop (Host) and Parallels Tools (Guest) and summarized the result in the following chart:

_	without host_inodes (default)	with host_inodes
Parallels Desktop v15 + Parallels Tools v15	SUCCESS, no inodes issue	FAIL, vagrant is failing, host_inodes is not supported by older prl_fs
Parallels Desktop v16 + Parallels Tools v15	SUCCESS, no inodes issue	FAIL, vagrant is failing, host_inodes is not supported by older prl_fs
Parallels Desktop v15 + Parallels Tools v16	FAIL, the issue with inodes exists	FAIL, host_inodes has no effect with older PD, the issue with inodes exists
Parallels Desktop v16 + Parallels Tools v16	FAIL, the issue with inodes exists	SUCCESS, host_inodes fixes the issue with inodes

Tested on: Parallels Desktop 15.1.4 (47270) and 16.0.1 (48919) Parallels Tools for Linux 15.1.47123 (box bento/ubuntu-18.04 v202003.31.0) and 16.0.48916 (box bento/ubuntu-18.04 v202008.16.0)

(parallels,) bento/ubuntu-18.04 (parallels, 202008.16.0)

Conclusions:

• The inode issue (#361) exists by default in all boxes having Parallels Tools v16
• The mount host_inodes fixes the issue #361 only when both host and guest parts are v16

Thank you very much for this PR, @MalteWunsch! But unfortunately we can't just merge it as is, because it will brake the backward compatibility with older (but still supported) versions of Parallels Desktop. We might need to add version checks of both host part and guest tools.

But first I'd like to ask if Parallels could shed some lite on it. @romankulikov @andreydanin @alevlasu Can you please tell us - is it a bug which will be fixed in some future version? Or is it the expected behavior, which we now need to adopt our provider to?

[legal90]

Hi all,

It seems that the issue was fixed in Parallels [Guest] Tools v16.1.49141 (available with Parallels Desktop v16.1.1) Starting since this version, inodes are persistent as it was before v16 major release, so there is no need to use host_inodes mount option anymore.

@MalteWunsch Thank you for your pull-request! However, as we can see from my previous comment, the option host_inodes is backward incompatible with older versions of Parallels Desktop. And it's also not needed starting since Parallels Tools v16.1.49141. That's why I think we should not enable host_inodes by default in the provider, so I'm gonna close this PR.

See my comment https://github.com/Parallels/vagrant-parallels/issues/361#issuecomment-735130465 for the instruction how to fix this issue.