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:
    6
    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:
    6
    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:
    2
    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:
    6
    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. PeterJ18

    PeterJ18 Bit Poster

    Messages:
    72
    Moving a record or envelope from a mutual organizer into My Drive is a move and not a duplicate, so the moved substance is expelled from the common envelope. Therefore:

    Clients will no longer observe the moved records or envelopes in the mutual organizer.

    Any consents on the moved substance that were acquired from the common organizer will be evacuated, and new authorizations will be acquired from the goal envelope (along with consents unequivocally set on a record or
     
  7. YanK

    YanK Bit Poster

    Messages:
    5
    Yes. The inode changes very quickly.
     

    Attached Files:

  8. 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
     
  9. FreekW

    FreekW Bit Poster

    Messages:
    6
    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)?
     
  10. 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
     
  11. 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
     
  12. FreekW

    FreekW Bit Poster

    Messages:
    6
    % uname -a
    Linux xb982-stretch 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64 GNU/Linux
     
  13. 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
     
  14. FreekW

    FreekW Bit Poster

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

    ParallelsU460 Bit Poster

    Messages:
    2
    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)
     
  16. mpdude

    mpdude Bit Poster

    Messages:
    11
  17. 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.
  18. PeterJ18

    PeterJ18 Bit Poster

    Messages:
    72
    You can move any file you own into a shared drive, whether it's from another Drive location or from your computer or mobile device.
    If you're not the owner of a file in My Drive, but you have at least Edit access to the file, you might be able to move that file into a shared drive, if:
    • Your G Suite admin has enabled this option.
    • The file's owner is a member of the shared drive where you want to move the file.
    Otherwise, you need to ask the owner to move the file into the shared drive.
     
  19. JohannesH5

    JohannesH5 Bit Poster

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

    (GalaxyMaster) Bit Poster

    Messages:
    26
    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 :-/
     

Share This Page