Hi everyone! I want to be able to access a folder inside the guest that corresponds to a cloud drive that is mounted inside the guest for security purposes. I have tried setting up a shared filesystem inside Virt-Manager (KVM) with virtiofs (following this tutorial: https://absprog.com/post/qemu-kvm-shared-folder) but as soon as I mount the folder in order for it to be accessible on the guest host the cloud drive gets unmounted. I guess a folder cannot have two mounts at the same time. Aliasing the folder using bind and then sharing the aliased folder with the host doesn’t work either. The aliased folder is simply empty on the host.

Does anyone have an idea regarding how I might accomplish this? Is KVM the right choice or would something like docker or podman better suited for this job? Thank you.

    • Atherel@lemmy.dbzer0.comEnglish
      2·
      2 months ago

      This, had the same idea for other purposes, sharing a folder from vm to host through network share is the easiest way. Every other solution looks more elegant on paper but has lots of pitfalls.

      • GathererStuffOPEnglish
        1·
        2 months ago

        Every other solution looks more elegant on paper but has lots of pitfalls

        A very sane and fair comment.

    • GathererStuffOPEnglish
      1·
      2 months ago

      What would be the performance implications? Isn’t virtiofs theoretically faster?

      • Appoxo@lemmy.dbzer0.comEnglish
        2·
        2 months ago

        Not an expert.
        Assuming it’s internal I’d assume it’s probably as fast as the guest nic allows?

    • GathererStuffOPEnglish
      1·
      2 months ago

      I can try but I might end up in the same situation as with virtiofs. The cloud drive will get unmounted and I will end up with an empty folder when I try to access it from the host.

  • DetachablePianistEnglish
    2·
    2 months ago

    Maybe see if ‘rclone mount’ solves the problem for ya. Rclone can often be a super handy swiss army knife for stuff like this.

    • GathererStuffOPEnglish
      1·
      2 months ago

      The cloud binary is proprietary and it’s not supported by rclone unless I find out how the binary works but I doubt it uses something standardized like WebDAV underneath.

  • NeoNachtwaechter@lemmy.worldEnglish
    1·
    2 months ago

    You say it is mounted. Then you can share it in all the same ways as you would share any other of the VM’s folders.

    I am using SMB shares for that (but that is not always the best way ofc).

    • GathererStuffOPEnglish
      1·
      2 months ago

      The cloud drive is mounted on the guest, yes, but once I mount it with virtiofs in order to share it with the host it gets unmounted and I end up with an empty folder. bind doesn’t work either.

    • GathererStuffOPEnglish
      1·
      2 months ago

      I strongly disagree why this would not be beneficial. Could you expand?

      • Possibly linux@lemmy.zipEnglish
        2·
        2 months ago

        You will need to mange the VM separately and the added hop (into the VM and then out again) will slow down performance and create another point of failure.

        Why would running it in a VM benefit security? Couldn’t you just mount it with fuse?

        • GathererStuffOPEnglish
          2·
          2 months ago

          Because the executable is proprietary (and a bit legacy I would say) and full of telemetry, undocumented and the cloud service has no CLI, WebDAV or rclone support. I do not want to run something like that on my personal computer and I do not know how to use bwrap properly and don’t want to risk it. I have since switched over to a podman container but I encounter the same problem, the folder is empty on the host (See my post here: https://lemmy.ml/post/22215540).

          • S_S@lemy.lolEnglish
            1·
            1 month ago

            I’ve used bubblewrap for many things and for a long time now, if you want to try that and have questions about it I think I can help, it is what I should have done in your scenario and what I have done much for the same reasons