Cannot move file in shared folder after upgrade to PD16

Discussion in 'Linux Guest OS Discussion' started by YanK, Aug 18, 2020.

Tags:
  1. YanK

    YanK Bit Poster

    Messages:
    5
    After upgrade to PD16, I cannot copy/move file in shared folders. See the attached files.
    Error is "cp: skipping file './test.cpp', as it was replaced while being copied".
    The Guest OS is Centos 7.5.1804.
     

    Attached Files:

    rjgebis likes this.
  2. FreekW

    FreekW Bit Poster

    Messages:
    7
    I have the exact same problem, trying to mv/cp in Debian Etch (4.9.228-1), on a machine running Catalina (10.15.6). Frustrating, please help!

    The relevant line in the output of mount is:
    Desktop on /media/psf/Desktop type prl_fs (rw,nosuid,nodev,noatime,sync,ttl=250,share)
     
  3. FreekW

    FreekW Bit Poster

    Messages:
    7
    I saw one thing that causes the problem: the inode of the files change all the time.

    % touch foo
    % ls -i
    3933173 foo
    % ls -i
    3933182 foo
    %
     
    YanK likes this.
  4. ParallelsU460

    ParallelsU460 Bit Poster

    Messages:
    4
    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.
     
  5. FreekW

    FreekW Bit Poster

    Messages:
    7
    I would be interested to know whether there are linuxes that do *not* suffer from this problem when accessing an APFS file system under Catalina. I.e., whether it's an distro-specific problem or not.
     
  6. YanK

    YanK Bit Poster

    Messages:
    5
    Yes. The inode changes very quickly.
     

    Attached Files:

  7. rjgebis

    rjgebis Kilo Poster

    Messages:
    186
    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
     
  8. FreekW

    FreekW Bit Poster

    Messages:
    7
    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)?
     
  9. rjgebis

    rjgebis Kilo Poster

    Messages:
    186
    $ uname -a
    Linux ubuntu 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
     
  10. YanK

    YanK Bit Poster

    Messages:
    5
    uname -a
    Linux localhost 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
     
  11. FreekW

    FreekW Bit Poster

    Messages:
    7
    % uname -a
    Linux xb982-stretch 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64 GNU/Linux
     
  12. tfb

    tfb Bit Poster

    Messages:
    2
    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
     
  13. FreekW

    FreekW Bit Poster

    Messages:
    7
    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.
     
  14. ParallelsU460

    ParallelsU460 Bit Poster

    Messages:
    4
    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:eek:bject_r:removable_t:s0,ttl=1000,share)
    git on /home/james/git type prl_fs (rw,nosuid,nodev,noatime,sync,context=system_u:eek:bject_r:removable_t:s0,ttl=1000,share)
     
  15. mpdude

    mpdude Bit Poster

    Messages:
    11
  16. tfb

    tfb Bit Poster

    Messages:
    2
    Note that this problem is still present in 16.0.1: the fix is the same.
     
    ParallelsU460 likes this.
  17. JohannesH5

    JohannesH5 Bit Poster

    Messages:
    4
    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?
     
  18. (GalaxyMaster)

    (GalaxyMaster) Kilo Poster

    Messages:
    92
    Well, in 16.0.1 it does not seem to work for me:
    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 :-/
     
  19. (GalaxyMaster)

    (GalaxyMaster) Kilo Poster

    Messages:
    92
    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.
     
  20. (GalaxyMaster)

    (GalaxyMaster) Kilo Poster

    Messages:
    92
    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:
    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 ~]#
    
    So we will see how it behaves after several reboots, kernel upgrades, etc.
     

Share This Page