Since so many people, including yours truly, struggle with being able to consistently connect to and use OMV SMB shares from a Windows client, I wanted to share a tip that quite possibly solves the issue once and for all.
Background:
Completely by accident, I happened to spot this entry in my syslog (under Diagnostics / System Logs in the web GUI):
Samba name server CUBESERV is now a local master browser for workgroup DOUBLEDA1M0N on subnet 172.17.0.1
where CUBESERV is, of course, my OMV machine and DOUBLEDA1M0N is the workgroup name I use on the server and all my Windows machines. (Don't ask - I don't even remember how I chose that name.) 
The IP address 172.17.0.1 is what made me nearly drop my jaw to the floor. Issuing ip a in a command shell revealed that this address belongs to my docker0 interface. "That's not what Samba should be listening to," I thought to myself. (More specifially, what the Samba name server nmbd should be listening to.)
I turned to my Google-fu and discovered the INTERFACES setting (which may be used in /etc/samba/smb.conf). And so...
The fix:
In the GUI, I went to the Services / SMB/CIFS page and added interfaces = br0 in the Extra options text box at the bottom, then applied changes when prompted.
My system is configured to use the bridge interface br0, whereas most users will want to use the standard Ethernet interface eth0 or eno1 or similar instead. The command ip a is helpful to show all of your active network interfaces and determine which one to use in the SMB/CIFS extra options.
The result:
I've been testing this on my Windows machines and haven't seen any timeouts or error messages browsing my network shares... nothing. It's working flawlessly. 
My main PC is currently installing Microsoft updates; once it reboots it will be interesting to see if the fix holds up (after a reboot, Windows tends to moan and bicker until it finally relents and connects to my OMV shares).
EDIT: It did. I think I got this licked. *excited*