My development machine for years was a Win10 VM running on VMWare Workstation on Ubuntu Linux. All files were on Samba shares on an ext4 partition on the same machine. I never encountered even a hiccup with an Access back end file. In fact, the machine had no NTFS partitions at all. Even the Windows VM files themselves resided on the same Samba shares on the Linux host system. I can't say what you tested but Access back end files, both MDBs and ACCDBs, can and do reside and operate without complaint on Linux Samba shares. No Linux application that I know of can open an ACCDB but that's obvious and beside the point.
To be clear, back end files don't "run" on the machine where they reside. That machine, regardless of OS or filesystem, is simply a file server. It isn't opening or running the back end file at all, just serving it to its client machine, in this case a Windows machine running Access, which opens the file. It is the msaccess.exe instances on users' machines that open both the front- and back-end files in a split Access database. Each user has a local front end file running on a local Access instance. All users' local Access instances then also open the same back end file, which resides on a remote share (Samba, workgroup, LDAP, AD, whatever). One bit of Access' magic is that it allows many front ends to simultaneously open the same back end file. Local machines' file and record locking settings configure this behavior somewhat. No back-end Access database server exists, however, just a back-end file, opened locally by each front end. In fact, one subtle optimization technique is to bind a startup or other application form to a back end table, to keep the back end file open instead of opening and closing it each time a user opens a form.