When a workstation loses communication with the EVO, the behavior is most often attributable to something external to the EVO, such as an interruption in connectivity at the switch or workstation.
The best first step if this happens is to determine whether or not other workstations are affected. If multiple clients experience the symptom at the same time, and they connect through a switch, then testing with any direct-to-EVO connections is recommended, as well as checking the switch.
Determining whether or not the EVO web interface is accessible in a web browser is another good test, to see if the workstation can reach the EVO network address in a different manner.
If the behavior is exclusive to a single machine, then troubleshooting should start at that machine.
If ShareBrowser is reporting that it's "unable to connect to server" it's possible that communication with the ShareBrowser database has been lost, while communication with the network share(s) is undisturbed, and no volumes actually become unmounted from the machine. Knowing the difference, and whether or not all machines experience the symptom, is helpful in determining whether or not the issue may be server-side.
If Finder/Explorer is reporting the volume is unmounted after the workstation was idle, one of the most frequent causes is the workstation's power settings. Modern personal computers are designed with energy-efficiency in mind, which is typically not ideal in a production environment. By default, machines will have several settings beyond just a simple on/off for standby, and will "sleep" individual components such as network adapters, even if they have active traffic.
Please see these articles for recommended power settings:
Some third-party network adapters may require individual tuning and/or consideration. If you're using an adapter with the Aquantia chipset for example (such as the Sonnet Solo), it may help to manually set the speed instead of letting the workstation automatically negotiate it.
Check that there's no inconsistency in how machines connect. SMB is the recommended protocol for current workflows, since it's cross-platform-friendly, and since Apple has deprecated AFP. Allowing more than one protocol on a network share can be problematic. It's also possible for a single machine to inadvertently duplicate the mount of the same volume if more than one protocol is allowed, which can lead to unexpected results.
If there's more than one network path to the EVO, ensure the correct one is used. For example, the EVO may have a 1GbE port connected to the router and accessible over Wi-Fi by anyone on the local network, while the workstation also has a dedicated 10GbE link to a separate port on EVO. The 10GbE adapter should be top priority in the service order, to help prevent the Wi-Fi route from ever being used (this is another way by which a machine may inadvertently mount a volume twice, creating inconsistency and possible conflict).
Ensure the MTU values match at each port in the connection path. EVO defaults to jumbo frames (9000 MTU) for its 10GbE ports, and standard frames (1500 MTU) for its 1GbE ports. Which frame size is chosen is not as important as making sure all ports in that subnet use the same value, at the EVO, workstation, and especially any switches in between.
Please open a support case if the above suggestions do not help!