Shared Folder - CPU load is up to 60% when using ConnectTCP

[qn00r3]

Hello.
CPU load goes up to 60% if I forget to unmount the shared folder.

Qubes OS 4.2.1
I’m using two cubes:

1. samba-qube (Shared folder on this cube).
2. mount-qube (I mount a shared folder to this cube).

Since there is no network connection on these cubes, I use qubes.ConnectTCP (Opening a single TCP port to other network-isolated qube):

Firewall

I’m running samba-qube.
I’m running mount-qube.
When you enable mount-qube, it mounts:

[user@mount-qube #]$ qvm-connect-tcp ::445
[user@mount-qube #]$ qvm-connect-tcp ::139
[user@mount-qube #]$ sudo mount -t cifs -o username=user,password=password //127.0.0.1/shared /home/user/samba/shared

Everything works great. But sometimes I forget to unmount the shared folder:

[user@mount-qube #]$ sudo umount /home/user/samba/shared

And I turn off samba-qube, it starts again automatically, as a result, the samba-qube CPU is loaded to 60% and in the mount-qube console I see a thousand lines:

2024/05/03 03:58:05 socat[640] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:05 socat[670] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[687] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[701] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[717] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[753] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[780] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[823] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[845] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:58:06 socat[890] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:33 socat[19981] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:33 socat[19994] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:33 socat[20007] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:33 socat[20020] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:33 socat[20033] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:34 socat[20046] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:34 socat[20059] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:34 socat[20072] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:34 socat[20085] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused
2024/05/03 03:59:34 socat[20098] E connect(5, AF=2 127.0.0.1:445, 16): Connection refused

All this happens for about 2-3 minutes, after which the directory is mounted and everything becomes fine.

My question: How to automatically unmount a shared folder in mount-qube when samba-qube is shut down?

P.S. I would be happy to hear other options for resolving this issue. Thank you.

[apparatus]

@qn00r3

My question: How to automatically unmount a shared folder in mount-qube when samba-qube is shut down?

I guess you can use another qrexec for this:

Qrexec: secure communication across domains

Create new qrexec service user.SambaUnmount, allow the qrexec call from samba-qube to mount-qube.
In mount-qube configure to unmount share after receiving the user.SambaUnmount service call.
On samba-qube shutdown call the user.SambaUnmount service to unmount share.

[qn00r3]

Thanks for Qrexec. Today I studied this and did some small experiments, I think I’m starting to understand how Qrexec works.
But the more I read about Qrexec, the more I understand that my approach to organizing a shared folder is not correct.
Initially, I wanted to use Samba and the general network between the cubes, until I came across the qubes.ConnectTCP method and concluded that I would disable the network between the cubes and use qubes.ConnectTCP.
But when I started learning about Qrexec, I had doubts about using qubes.ConnectTCP + Qrexec.
I thought that it might be possible to limit myself to only one Qrexec, I came across a guide (Guide: Rsync from multiple qubes to one over qrexec):

Guide: Rsync from multiple qubes to one over qrexec

Hi everyone, It took me a while to figure this procedure out properly, so I thought it might be useful also for others. Big thanks to @unman who pointed me in this direction and who wrote very helpful instructions which are the basis of this procedure. As I’m still new to QubesOS, I’m also curious about feedback/comments from the qubes community on this guide. Context Let’s assume the following qube structure: data1 and data2: Offline storage qubes with large amount of data that changes o…

The man made a connection between cubes without using qubes.ConnectTCP, he used Qrexec + Rsync.
And I thought that it might be possible to make a shared folder using Qrexec + Samba, but I’m not sure about it.

Based on the above, I have some questions:

1. Do you think it is possible to organize a shared folder using Qrexec + Samba?
2. If it is possible to organize a shared folder using Qrexec + Samba, then how to open TCP ports 139/445 using Qrexec?

[apparatus]

If you want to have shared folder between qubes then you can use this:

GitHub - Rudd-O/qubes-shared-folders: Easily share folders between VMs.

@qn00r3

Based on the above, I have some questions:

1. Do you think it is possible to organize a shared folder using Qrexec + Samba?
2. If it is possible to organize a shared folder using Qrexec + Samba, then how to open TCP ports 139/445 using Qrexec?

You can replace qubes.ConnectTCP with Qrexec and socat:
Here is an example:

User Guides: CLI Wallet/Daemon Isolation with Qubes + Whonix

But it’s using old qrexec format so you need to change it to the new one. Like this for example:

Guide: split-Protonmail (offline send/receive qubes + pm bridge vm)

Thanks again for writing up this guide! I think we can update some things so that it’s locked down even more, in particular we can eliminate the need to allow arbitrary TCP connections between the qubes. The new policy file (using the new fromat described at Qubes Architecture Next Steps: The New Qrexec Policy System | Qubes OS) looks like this, in /etc/qubes/policy.d/30-protonmail.policy: # Always allow connection to imap. Thunderbird will give you 2 pop-ups every # time it checks for new mes…

[qn00r3]

Thanks for your links, I’ll look into them.
Regarding qubes-shared-folders, I paid attention to it from the very beginning, it seemed very convenient to me and judging by the author’s posts on this forum, the author is a very meticulous person, which is very pleasing.
The only thing that confuses me is the installation of this software in dom0, due to the fact that I do not understand Linux, for me any failures and errors can be fatal, because I cannot quickly fix them on my own.
Based on the above, I would like to hear your opinion, if possible.
The question is:
Which would you recommend using, qubes-shared-folders or Qrexec + Socat ?

[apparatus]

@qn00r3

Which would you recommend using, qubes-shared-folders or Qrexec + Socat ?

Personally I’d go for qubes-shared-folders that was carefully thought through for a long time instead of trying to reinvent the wheel and encounter every issue that was fixed in qubes-shared-folders and maybe even more on the way.

But you can still go for qrexec+socat+samba. It’s not really that complicated to set up. But it’s not very user-friendly, missing some features and maybe less performant compared to qubes-shared-folders.

[qn00r3]

Thanks for the help, I figured out Samba + Qrexec + Socat.
Last question, if you use Samba + Qrexec + Socat for a group of virtual machines (A,B,C), and qubes-shared-folders for a group of virtual machines (D,E,F), will there be any conflicts between these technologies?

[apparatus]

No, there shouldn’t be any conflict.
At least if you won’t use the same qrexec policy names for your samba+qrexec+socat that is already used in qubes-shared-folders.

[qn00r3]

I implemented Systemd Unit so that after shutting down the samba-qube virtual machine, the shared folder in the mount-qube virtual machine would be automatically unmounted.
My Systemd Unit on the samba-qube virtual machine:

[Unit]
Description=Before System Reboot or Poweroff
After=systemd-user-sessions.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/rw/config/reboot-poweroff-script
Restart=on-failure
RestartSec=13s

[Install]
WantedBy=multi-user.target reboot.target poweroff.target

I decided to check the entry in the log file before starting work, the contents of the reboot-poweroff-script:

#!/bin/sh
qrexec-client-vm mount-qube reboot-poweroff.script

On the mount-qube virtual machine, the contents of the reboot-poweroff.script:

#!/bin/sh
echo "it works..." >> /home/user/Desktop/script.log

Logically, after shutting down the samba-qube virtual machine, the mount-qube virtual machine should write to the script.log file.
But this doesn’t happen.
It’s interesting that at first I thought that I had written the wrong Systemd Unit, which was causing this problem, then I ran the command to stop the Systemd Unit on the samba-qube virtual machine:

[user@samba-qube]$ sudo systemctl stop reboot-poweroff.service

And everything worked, on the mount-qube virtual machine the script.log file was written to the log file, but when the samba-qube virtual machine was turned off or rebooted, the script.log file was not written to the log file.

Then I decided to rewrite the reboot-poweroff-script script, so that the log file script.log would be written on the same virtual machine (samba-qube) where the Systemd Unit is located (so as not to use Qrexec), the contents of the reboot-poweroff-script:

#!/bin/sh
echo "it works..." >> /home/user/Desktop/script.log

Rebooted the samba-qube virtual machine and checked the entry in the script.log file:

[user@samba-qube]$ cat /home/user/Desktop/script.log
[user@samba-qube]$ it works...

Everything works, this means that my Systemd Unit is written correctly, the problem lies in Qrexec, after rebooting the system or turning off the samba-qube virtual machine, writing to the script.log file using Qrexec does not occur.
If you rewrite Systemd Unit so that writing to the file occurs after turning on the samba-qube virtual machine using Qrexec, this will work. But if Systemd Unit is configured to start Qrexec after shutting down the samba-qube virtual machine, nothing works.
Have you encountered this? I don’t understand why Qrexec doesn’t want to work after shutting down the virtual machine.

[qn00r3]

The problem was in Systemd Unit, you need to remove the line:
After=systemd-user-sessions.service

Write instead:
After=qubes-qrexec-agent.service

The solution was found on the forum:

Systemd: Let qube shutdown another qube

Found it out. As described in https://groups.google.com/g/qubes-users/c/RogG5rXG_Pw, you need to ensure, qrexec-client-vm is invoked, when qubes-qrexec-agent.service is still active. Hence add following to shutdown.service (under [Unit] section): After=qubes-qrexec-agent.service Also it needs to be a system - not user - service.