Well-behaved services don't need restarts after a configuration change...they just read the new configuration. How they handle current connections when this happens depends of the type of service and what changed. For SMB, adding a new share shouldn't even be a blip on already connected sessions to existing shares. Changing the config of an existing share...that might require connections to be dropped.
See comments above. The situations where restart is warranted are limited.
I figured that was the case, but I wasn't sure if Samba on TrueNAS had any differences from the reference code.
No, generally we try to avoid restarting services unless we absolutely must, it's best avoid impacting production. For instance, when user renames an SMB share we will close the original share (disconnecting clients to it), then create the new one rather than forcing a service restart. Least invasive approach is preferred because it should be up to the sysadmin whether to take more production-impacting steps. This is why we have some prompts saying basically "if you're doing one of these things, you may wish to restart the SMB service".
Ok, super, my thought was that it was mandatory. I do have to restart "/usr/sbin/service avahi-daemon restart" avahi to get a new or updated Timemachine share to propagate out.
We force reload of avahi on SMB share add if it is time machine share. Perhaps the clients are slow to pick up changes (mDNS is notoriously spotty).
