My suggestion is always to install the file services which are natively supported by the clients. The main benefit is that you can mount network drives on the clients which do smoothly integrate into a desktop workflow. I do not consider FTP native in this respect - on all clients which I know, it feels like an add on. So yes, basically I support the suggestion of SirDice, although, I use
net/samba410 for Windows clients only. For my macOS clients I use
net/netatalk3 which was more performant, although the last comparing measurement was a few years ago (against samba 3.x).
Since I need only the file services, I strip down the samba4 build options to the bare minimum:
Code:
┌──────────────────────────── samba410-4.10.8_1 ───────────────────────────────┐
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ [ ] ADS Active Directory client(implies LDAP) │ │
│ │ [ ] AD_DC Active Directory Domain Controller │ │
│ │ [x] AESNI Accelerated AES crypto functions(amd64 only) │ │
│ │ [ ] CLUSTER Clustering support │ │
│ │ [ ] CUPS CUPS printing system support │ │
│ │ [ ] DEBUG Build with debugging support │ │
│ │ [ ] DEVELOPER With developer framework(implies NTVFS) │ │
│ │ [x] DOCS Build and/or install documentation │ │
│ │ [ ] FAM File Alteration Monitor │ │
│ │ [ ] GPGME GpgME support │ │
│ │ [ ] LDAP LDAP client │ │
│ │ [ ] MANDOC Build manpages from DOCBOOK templates │ │
│ │ [ ] NTVFS Build *DEPRECATED* NTVFS file server │ │
│ │ [ ] PROFILE Profiling data │ │
│ │ [ ] QUOTAS Disk quota support │ │
│ │ [ ] SPOTLIGHT Spotlight server-side search support │ │
│ │ [x] SYSLOG Syslog logging support │ │
│ │ [x] UTMP UTMP accounting │ │
│ │─────────────────────────────── VFS modules ──────────────────────────────│ │
│ │ [ ] FRUIT MacOSX and TimeMachine support │ │
│ │ [ ] GLUSTERFS GlusterFS support │ │
│ │─────────────────────── GSSAPI Security API support ──────────────────────│ │
│ │ (*) GSSAPI_BUILTIN GSSAPI support via bundled Heimdal │ │
│ │ ( ) GSSAPI_MIT GSSAPI support via security/krb5 │ │
│ │────────────────────── Zero configuration networking ─────────────────────│ │
│ │ (*) ZEROCONF_NONE Zeroconf support is absent │ │
│ │ ( ) AVAHI Zeroconf support via Avahi │ │
│ │ ( ) MDNSRESPONDER Zeroconf support via mDNSResponder │ │
│ │─────────────────────────────── DNS frontend ─────────────────────────────│ │
│ │ ( ) NSUPDATE Use samba NSUPDATE utility for AD DC │ │
│ │ ( ) BIND911 Use Bind 9.11 as AD DC DNS server frontend │ │
│ │ ( ) BIND914 Use Bind 9.14 as AD DC DNS server frontend │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────────────────┤
│ < OK > <Cancel> │
└──────────────────────────────────────────────────────────────────────────────┘
If you want zeroconf support, then be aware that Avahi drags-in tons of Poettering's stuff, while mDNSResponder besides being the original is still quite slim.
Finally, none of my Windows clients are configured to use the same user/password for Windows login and the Samba shares. I login to the samba shares on demand, and usually logout after I am ready. The possibility of a ransomware trojan gets access to some of my file services makes me scared.
Of course none of the file services, ftp, nfs, smb, afp are accessible via the internet. Mobile clients would need to establish a VPN connection first.