SMB mount point location

[John Maher]

Hello,

I'm trying to access file on the command line through an SMB mount point that is created in the GUI. I'm using a debian-8 AppVM and connecting to an SMB share in a Files window, but I cannot find a mount point for the share. I would expect it to be in /run/users/1000/.gvfs, but there's nothing there.

Can anyone point out where I would find that mount point?

Thank you very much.

John

[Manuel Amador (Rudd-O)]

By default, GVFS won't actually mount it — it just appears in the Files
window. I believe the first time you attempt to activate (open) a file
on the share, GVFS does the mount. It used to be different, I know, I
just hit this issue myself a few days ago.

This is more a GNOME upstream thing.

Do your files show on the file manager?


--
Rudd-O
http://rudd-o.com/

[John Maher]

On Wednesday, October 12, 2016 at 12:06:15 PM UTC-4, Manuel Amador (Rudd-O) wrote:

> Do your files show on the file manager?

Manuel, thank you for responding. Yes, they do. So, there is no way to access the files through the connection created by the file manager?

[John Maher]

On Wednesday, October 12, 2016 at 12:06:15 PM UTC-4, Manuel Amador (Rudd-O) wrote:

The real issue is that I'm trying to access a KeePassX database that resides on a smb share, and the Database > Open dialog box does not present mounted smb shares or bookmarks to the shares. Any thoughts on this?

[Manuel Amador (Rudd-O)]

You need an actual mount for that to work, and the dialog box will not
trigger the mount operation. You have two choices:

1) Open your KeepAssX database in a StandaloneVM which you have
configured to mount the SMB drive.
2) In the template, create and enable an /etc/systemd/system mount unit
for the SMB drive, that is only active if a file in
/var/run/qubes-service/<SERVICEFILE> exists (check the various
qubes-*.service files in /usr/lib/systemd/system for examples on how the
ConditionPathExists thing works), then set up the qubes-service
<SERVICEFILE> on the VM in question. That way, when you boot the VM in
question, and only that VM in question, the mount appears immediately.

I would also use automount units if I were you, just to make sure that
your VM where you run KeepAssX boots fast and does not wait to mount the
remote device.

Here is a crude example of such a thing:

[user@tpl ~]$ mkdir /mnt/keepassxmount
[user@tpl ~]$ cat > /etc/systemd/system/mnt-keepassxmount.mount
[Unit]
Description=Mount /mnt/keepassxmount
ConditionPathExists=/var/run/qubes-service/mnt-keepassxmount
Before=remote-fs.target
After=remote-fs-pre.target mnt-keepassxmount.path

[Mount]
What=//smbserverip/keepassxmount
Where=/mnt/keepassxmount
Type=cifs
Options=_netdev,cache=strict,forceuid,forcegid,noperm,noserverino,nomapposix,nomapchars,uid=user,gid=user,forceuid,forcegid

[Install]
WantedBy=remote-fs.target
[user@tpl ~]$ systemctl enable mnt-keepassxmount.mount

At this point you add the Qubes service mnt-keepassxmount in your VM's
configuration.

Option 3: use some file sync service to keep that KeepAssX file
synchronized to local disk on that VM.


--
Rudd-O
http://rudd-o.com/

[John Maher]

Manuel, this is awesome! Thank you for the extensive explanation.

Regarding option 3, are you referring to a Qubes service or some other type of utility? Being new to Qubes, your mentioning of services above is my introduction to Qubes services.

John

[Manuel Amador (Rudd-O)]

On 10/18/2016 07:25 PM, John Maher wrote:
>
> Manuel, this is awesome! Thank you for the extensive explanation.

My pleasure.

>
> Regarding option 3, are you referring to a Qubes service or some other type of utility? Being new to Qubes, your mentioning of services above is my introduction to Qubes services.

What I outlined, effectively speaking, is a simple solution that allows
you to set up (on the TemplateVM) a systemd mount unit which only
triggers (on the AppVM) when the service /mnt-keepassxmount/ has been
added and activated in the /Services/ tab of the settings dialog for the
AppVM. None of your VMs (not the template, and not any other VMs based
on the template) will try to mount that file system, EXCEPT for the VM
in which /mnt-keepassxmount/ service has been activated.

Most of the learning complexity of the example I presented is
essentially the difficulty of learning stuff like mount units (man
systemd.mount).

The setup of the mount unit (creation of the /etc file and systemd
enable) needs to be done in the template because the root file system of
your AppVM is going to be based *afresh* on the template VM, *every
time* and your AppVM boots. When you enable the Qubes service
"mnt-keepassxmount", systemd attempts to activate the unit you created
(based on my example), resulting in the mount taking place.

Note that the target mount point (in my example /mnt/keepassxmount,
illustrated by mnt-keepassxmount.path in the unit file) must already
exist. If your mount point is going to be in /home or /rw, then you can
create that mount point in the AppVM. If your mount point is going to
reside outside those two places, then the mount point must exist in the
TemplateVM.

If your VM is a StandaloneVM with its own independent root file system,
then the changes must be done in the StandaloneVM, not on any template.

--
Rudd-O
http://rudd-o.com/

[John Maher]

Manuel,

So helpful! Thank you very much for your explanation.

John