How to Activate a Mount of a Remote Share When Its Machine Connects?

Question

How can one activate a mount of a remote SMB share when the remote machine connects?

This is more about discerning a local event triggered by the connection of a particular remote machine, than it is about the action taken on that event. What can be determined is the port and protocol, of course, probably the source IP, and perhaps its MAC.

To illustrate, imagine two Windows laptops named Blue and Green, each with a share named Data, that occasionally connect to a Linux Samba server named Martini. The objective is for Martini to mount \Blue\Data to /srv/blue (or wherever)(and do other things) when Blue connects, and mount \Green\Data to /srv/green (or wherever)(and do other things) when Green connects.

Perhaps I'm too deep in the weeds but this seems harder than it looks.

It's straightforward to mount a remote share when localhost connects to it, e.g., when Martini boots, does its thing, finds Blue and Green running, and mounts their shares.

I even have figured out how to activate a host mount of a share on a virtual machine when it fires up (create a systemd.path unit that monitors the VM's log file, then x-systemd.requires=foo.path in fstab).

For a fully remote machine, however, I'm drawing a blank. There is a roundabout / Rube Goldberg way via the iptables LOG target and rsyslog (directly or via a systemd.path unit) but that has too many moving pieces and seems like a kludge. The hope is that something more direct exists.

Socket activation can mind a port but (and I easily could be wrong) isn't obviously capable of discerning the connecting machine. Udev activation seems focused only on localhost's hardware. I haven't figured out a client-wise /dev, /proc, or other path to inspect, although I easily could have missed something. Perhaps there is something in /etc/samba/smb.conf.

Pending further tail-chasing, I thought I'd post to see what ideas the community might have. Any input would be most appreciated.

Answer 1

Perhaps I'm too deep in the weeds but this seems harder than it looks.

You are entirely correct: at the level of the SMB protocol, it is indeed harder than it looks like in the user's perspective!

A single SMB client host may utilize multiple TCP connections in parallel, and if a connection is broken while not actively used (e.g. because of a network error or long time of inactivity), a client may "seamlessly" reconnect when the connection is again needed, while giving the user the appearance that the connection has been active all along.

These, among other things, can make it hard or impossible to do what you are asking by naively parsing Samba's logs.

You might or might not care about this possibility of triggering your things possibly multiple times in parallel, or needlessly when the "new connection" is in fact a re-establishment of an existing connection.

To gain access to the necessary protocol details so that you can recognize and avoid these issues, you might have to write a custom Samba VFS module that will allow you to hook your things to the appropriate protocol events, and maintain the necessary state information to avoid false triggering.

From the document linked above:

Please note, if your VFS module should only perform connect-time actions on the first connection, and disconnect-time actions on the last disconnect, you should carefully manage that in your module. If you configure multiple shares to use your VFS module you should be aware that your connect and disconnect functions will be called once for each such share that the user connects to.

Similarly, since Samba uses a fork model, where each client gets a separate smbd, your connect function will be called in each smbd for each share that uses the module that clients connect to.

A suggestion to start a Samba VFS module programming project to suit your needs is probably not what you were looking for, but based on your stated requirements, I know of no other solution that could be called even somewhat reliable.

I would be wary of the idea of parsing the Samba logs to trigger your things: depending on various details, you might need to increase the Samba loglevel so high to get the events suitable for your purposes, that the volume of resulting logs may force you to trade one problem for another.

I trust you now understand why I tried to "turn every stone" to seek the possibilities for alternative approaches.