Virtually any file system you apply to a Linux operating system (such as Ubuntu) will have ACL capabilities. ACL is an acronym for "Access Control List." In simple terms, it means the file system is capable of restricting access to files and folders (directories) based on a user's credentials.
Why would anyone want a file system that doesn't support ACL?
Speed. A 10-year study conducted between 1993 and 2003 concluded that without ACL, a file system can be over 500 times faster the first time a file is accessed from disk. Granted, on modern systems that figure has no doubt come down, however what is perhaps more telling is the range of impact caused by an ACL in terms of initial file transfer times. The quickest file system in the study had a 1:1 ratio of time for non-ACL to ACL comparisons, while the file system that was impacted most profoundly was slowed down 538 times when ACL was implemented.[1]
The Trade-off Triad: Security, Integrity, and Speed
Security, data integrity, and speed are more-or-less mutually exclusive properties, though there is an indirect positive relationship between security and data integrity (authenticity). In some cases - within a closed-end system perhaps - integrity may be paramount over security (and in such cases, one can improve transfer speed by making sacrifices to security levels).
Some ACL file systems are more robust than others from the standpoint of how difficult it is to compromise them. Bear in mind this is not a typical file system access issue concerning local file access. Rather, we are concerned with remote access, and specifically the impact of an ACL file system as it pertains to Samba, which means when a server is sharing (host server) or accessing (remote server) data across a network.
The file system is the root layer of access control. Samba depends upon it, because NFS is an implied trust model file system. SMB quite frankly doesn't have a clue. NFS does partially, but it essentially trusts whatever you tell it is reality. And this is why your protection truly boils down to the file system.
Samba as Universal Translator: NFS vs. SMB
Samba has no knowledge of what is happening behind the scenes of either the client or host device. When initiating a connection, you may think of Samba as knocking on the front door of the opposing device. Samba doesn't know what is going on behind closed doors. It only knows what it's looking for (receiving) or offering (sending), and who is purportedly the owner (Samba's user name/group). Samba presumes the remote server is responsible with its data management.
The implied trust model of Samba creates opportunities (especially in the Linux world) that can conceivably allow a bad actor to compromise a connected system, including the ability to run commands or move files, elevate the user to root level, and remotely execute a file with root access. The final stop-gap to preventing devastating intrusions via a compromised Samba account is via strict ACL file enforcement on the host.
[1] Grünbacher, A. (2003). SuSE Labs. POSIX Access Control Lists on Linux. https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html