Cannot move file in shared folder after upgrade to PD16
- Thread starter YanK
- Start date
ParallelsU460
Bit poster
Same here. Opened a support case for it, but was told my guest vm isn't supported (although it is according to their docs).
On RHEL 8.2, latest kernel, with dkms. Everything was working fine after the upgrade to 16, but after upgrading the Parallels Tools that's when I started getting this. I'm guessing the prl_fs changed and the kernel modules don't work for it.
On RHEL 8.2, latest kernel, with dkms. Everything was working fine after the upgrade to 16, but after upgrading the Parallels Tools that's when I started getting this. I'm guessing the prl_fs changed and the kernel modules don't work for it.
Yes. The inode changes very quickly.
Attachments
I have same issue and reported it. So far I can not get any info. First level support is very useless. Just got of the phone with one of them and was struggling finding "Take VM snapshot" in its own product.
Ehh. Back to this issue. I only have this problem when trying to copy file from within VM using terminal "cp" command. Copying using Caja file Manager (Ubuntu Mate 20.04) works fine
$ cp /media/psf/VShare/dev-setup.tar .
cp: skipping file '/media/psf/VShare/dev-setup.tar', as it was replaced while being copied
Ehh. Back to this issue. I only have this problem when trying to copy file from within VM using terminal "cp" command. Copying using Caja file Manager (Ubuntu Mate 20.04) works fine
$ cp /media/psf/VShare/dev-setup.tar .
cp: skipping file '/media/psf/VShare/dev-setup.tar', as it was replaced while being copied
The relevant code in the source of cp is:
/* Compare the source dev/ino from the open file to the incoming,
saved ones obtained via a previous call to stat. */
if (! SAME_INODE (*src_sb, src_open_sb))
{
error (0, 0,
_("skipping file %s, as it was replaced while being copied"),
quoteaf (src_name));
return_val = false;
goto close_src_desc;
}
That's why the fact that the inode changes all the time causes this error, and why if some other program doesn't do this check there isn't a problem. So I wonder what can cause the inode to change. It seems a problem in the prl_fs driver. But does it make a difference what kernel you are running (in my case 4.9.0-13-amd64)?
/* Compare the source dev/ino from the open file to the incoming,
saved ones obtained via a previous call to stat. */
if (! SAME_INODE (*src_sb, src_open_sb))
{
error (0, 0,
_("skipping file %s, as it was replaced while being copied"),
quoteaf (src_name));
return_val = false;
goto close_src_desc;
}
That's why the fact that the inode changes all the time causes this error, and why if some other program doesn't do this check there isn't a problem. So I wonder what can cause the inode to change. It seems a problem in the prl_fs driver. But does it make a difference what kernel you are running (in my case 4.9.0-13-amd64)?
Here is a workaround for this on Ubuntu 20.04, which I suspect will work everywhere.
As other people have found, the problem is that the inodes for files in shared directories are wildly unstable. It turns out that there's a manual page for mount.prl_fs, which tells you about an option called host_inodes, which appears to make the inode numbers stable (it passes through inode numbers from the underlying filesystem).
So, then I spent some time working out how the tools actually mount things, and, at least on Ubuntu this is, thankfully, not via some systemd horror, but by a little daemon which is /usr/bin/prlfsmountd. And that's a shell script! So you can edit it - it already uses host_inodes for home directories, but you can just force it to use this option everywhere. Below is a diff, but you can just add it by hand to MNT_OPS in the script. I then bounced the VM and it's fine (I didn't bother working out how to restart it all with the VM up).
With luck this will make it into a patch release: it looks like a small problem for once.
---cut for diff, I hope this does not get mangled---
--- prlfsmountd.20200830 2020-08-11 13:43:45.218411070 +0100
+++ prlfsmountd 2020-08-30 12:52:45.112938240 +0100
@@ -9,7 +9,7 @@
MOUNTS=/etc/mtab
SF_LIST=/proc/fs/prl_fs/sf_list
POLL_TIME=5
-MNT_OPS=sync,nosuid,nodev,noatime,share
+MNT_OPS=sync,nosuid,nodev,noatime,share,host_inodes
# In addition to MNT_OPS for the Home folder
MNT_OPS_HOME=host_inodes
PRL_LOG=/var/log/parallels.log
As other people have found, the problem is that the inodes for files in shared directories are wildly unstable. It turns out that there's a manual page for mount.prl_fs, which tells you about an option called host_inodes, which appears to make the inode numbers stable (it passes through inode numbers from the underlying filesystem).
So, then I spent some time working out how the tools actually mount things, and, at least on Ubuntu this is, thankfully, not via some systemd horror, but by a little daemon which is /usr/bin/prlfsmountd. And that's a shell script! So you can edit it - it already uses host_inodes for home directories, but you can just force it to use this option everywhere. Below is a diff, but you can just add it by hand to MNT_OPS in the script. I then bounced the VM and it's fine (I didn't bother working out how to restart it all with the VM up).
With luck this will make it into a patch release: it looks like a small problem for once.
---cut for diff, I hope this does not get mangled---
--- prlfsmountd.20200830 2020-08-11 13:43:45.218411070 +0100
+++ prlfsmountd 2020-08-30 12:52:45.112938240 +0100
@@ -9,7 +9,7 @@
MOUNTS=/etc/mtab
SF_LIST=/proc/fs/prl_fs/sf_list
POLL_TIME=5
-MNT_OPS=sync,nosuid,nodev,noatime,share
+MNT_OPS=sync,nosuid,nodev,noatime,share,host_inodes
# In addition to MNT_OPS for the Home folder
MNT_OPS_HOME=host_inodes
PRL_LOG=/var/log/parallels.log
Yes! This solves it for me, thank you, thank you *very* much!
I guess it's off in that script because of a reason related to the sentence in the manual: "Note that if [there an]other filesystems are mounted at the host within the shared folder's directory tree, they all won't be accessible to avoid collisions on inode numbers." Which I don't really understand. But my two shared folders are non-overlapping, so I guess that won't affect me.
I guess it's off in that script because of a reason related to the sentence in the manual: "Note that if [there an]other filesystems are mounted at the host within the shared folder's directory tree, they all won't be accessible to avoid collisions on inode numbers." Which I don't really understand. But my two shared folders are non-overlapping, so I guess that won't affect me.
ParallelsU460
Bit poster
tfb's solution works for me too. Not sure why, but I do not see that mount option in mount's output though :
shared on /media/psf/shared type prl_fs (rw,nosuid,nodev,noatime,sync,context=system_u
bject_r:removable_t:s0,ttl=1000,share)
git on /home/james/git type prl_fs (rw,nosuid,nodev,noatime,sync,context=system_ubject_r:removable_t:s0,ttl=1000,share)
shared on /media/psf/shared type prl_fs (rw,nosuid,nodev,noatime,sync,context=system_u
bject_r:removable_t:s0,ttl=1000,share)git on /home/james/git type prl_fs (rw,nosuid,nodev,noatime,sync,context=system_u
bject_r:removable_t:s0,ttl=1000,share)For those using Vagrant to control guest VMs, a fix for the Parallels Vagrant Plugin is at https://github.com/Parallels/vagrant-parallels/pull/362.
JohannesH5
Bit poster
I have the same problem when copying a file to the virtual machine from a shared folder.
Using the "ls -i FILENAME" I can see that the inode keep changing all the time.
Is there any patch in the making that will adress this issue?
Using the "ls -i FILENAME" I can see that the inode keep changing all the time.
Is there any patch in the making that will adress this issue?
(GalaxyMaster)
Hunter
Well, in 16.0.1 it does not seem to work for me:
As you may see from the output above, the "host_inodes" option has not been set on the mount despite being explicitly requested.
According to the code in prl_fs/super.c in prlfs_fill_super():
Which, basically, says that even if "host_inodes" was explicitly requested but the Toolgate does not support it for some reason the option is going to be disabled.
So far, I could not find why it is not enabled :-/
Code:
[root@archlinux parallels-tools-16.0.1.48919]# mount -v -t prl_fs -o host_inodes,share Home /mnt/psf/Home
mount: Home mounted on /mnt/psf/Home.
[root@archlinux parallels-tools-16.0.1.48919]# mount | fgrep Home
Home on /mnt/psf/Home type prl_fs (rw,relatime,sync,ttl=300,share)
[root@archlinux parallels-tools-16.0.1.48919]# cp /mnt/psf/Home/.bash_history test
cp: skipping file '/mnt/psf/Home/.bash_history', as it was replaced while being copied
[root@archlinux parallels-tools-16.0.1.48919]# umount /mnt/psf/Home
[root@archlinux parallels-tools-16.0.1.48919]#As you may see from the output above, the "host_inodes" option has not been set on the mount despite being explicitly requested.
According to the code in prl_fs/super.c in prlfs_fill_super():
Code:
...
if (prlfs_sb->host_inodes) {
struct prlfs_sf_features sff = {PRLFS_SFF_HOST_INODES};
if ((get_sf_features(tg_dev, &sff) < 0) || !(sff.flags & PRLFS_SFF_HOST_INODES))
prlfs_sb->host_inodes = 0;
}
...Which, basically, says that even if "host_inodes" was explicitly requested but the Toolgate does not support it for some reason the option is going to be disabled.
So far, I could not find why it is not enabled :-/
(GalaxyMaster)
Hunter
Ok, I dove into the code of `super.c` and found that it has nothing with the Toolgate. I also found why `mount` does not report the "host_inodes" in its output - prlfs_show_options() just was not updated to report that option back.
(GalaxyMaster)
Hunter
I think there is an issue with how Parallels are parsing the mount options (they are using strsep() for this and the function is destructive to its first argument), but right now the module works after I recompiled, unloaded, and loaded it back zillion times. There is a chance that the memory is actually corrupted somewhere (I had a version of the module where it was duplicating the option string before feeding it through strsep() and it was the first iteration that actually worked).
Anyway, now I have the module reporting through /proc/mounts that the option was indeed applied:
So we will see how it behaves after several reboots, kernel upgrades, etc.
Anyway, now I have the module reporting through /proc/mounts that the option was indeed applied:
Code:
[root@archlinux ~]# cat /proc/mounts | fgrep Home
Home /mnt/psf/Home prl_fs rw,sync,nosuid,nodev,noatime,ttl=300,share,host_inodes 0 0
[root@archlinux ~]#