Ah ok, so if there's no Windows and all clients are Ubuntu certainly makes things better IMO!

So personally I'd say if you're not using Windows and have no need (or intentions) for Windows to access files, then why use a Windows protocol?

If you're happy to step back from SMB, then there are lots of different options you could use to share files. NFS is probably worth consideration as it's probably the one most suited to this job. I don't have much experience with it and can't offer much OOTOMH guidance, but our Fileserver appliance should support it OOTB.

My personal favourite networking filesharing method is via SSHFS. Although I'm not sure how well it would work with multiple users? I use it lots but not with files shared with others; just amongst my devices.

Alternatively, you could look to leverage a filesyncing (Dropbox-like) tool to auto sync files. One of the most popular (of our appliances) is Nextcloud. When peered with a client app, it essentially provides a Dropbox-like experience, plus it has a pretty, extendable webUI that allows you to do tons of stuff with your files.

If that seems a bit overkill (which it possibly is) then we also have a Syncthing appliance. That is much more simple and focuses on just the file syncing part.

You seem to have a fundamental misunderstanding about what network "file shares" are. Your "FTP style stuff" comment was what alerted me to that, so let me first try to educate you a little. Sorry that this post is quite long and I also apologies in advance if this feels like a bit of a rant, but I'd urge you to read through it all. Hopefully it will help you understand the full complexity and associated trade-offs.

Network "file share" protocols

Network "file shares" are merely the ability to access remote file systems via a network protocol. You could consider a network protocol as being like a language. The only fundamental difference between an FTP share and an SMB (i.e. Windows file sharing protocol) share is the network protocol (i.e. the "language") used. For file shares to work, both the "server" and the "client" need to be able to connect via the same protocol - i.e. "speak the same language".

Whilst the protocol itself is unique, SMB is not fundamentally different to; or better than (S)FTP, NFS, WebDAV (via HTTP or HTTPS) or any other network file sharing protocol. My guess is that your experience with Windows has lead you to the mistaken idea that windows file sharing is "just plain old straight file sharing" - it's not!

It's just the native and default Windows file sharing protocol; just like AFP (Apple Filing Protocol) is the native and default file sharing protocol in the Apple ecosystem and "just works" between Apple devices. But because Windows has the biggest PC market-share, that means that SMB is very common and pervasive (to the point that Apple supports it too). Because Linux is open source, quite fragmented and has a small market-share (at least in the end user PC market), it supports many native (e.g. NFS) and non-native protocols (e.g. SMB and AFP) and it doesn't really have a single "default" protocol.

Possibly one other factor that has lead you to think that SMB is "just plain old straight file sharing" is that unlike many protocols, by default it advertises itself on the network. It essentially yells "hey here I am, come connect to me!". I'll speak to that a little more with below as it's quite relevant to connection via your file manager.

File manager network file share support

Whether or not a particular file manager aka "client" (e.g. Nautilus, Caja, Windows Explorer or whatever file manager you're using) can mount shares of any particular protocol or not depends on the file manager itself. (Obviously it also depends on how the shares have been set up too, e.g. permissions, etc). My guess is that your only experience with "FTP style stuff" has been via a specific FTP client (i.e. a file manager that explicitly supports FTP and often FTP variants only). For what it's worth, Windows Explorer (Windows built-in native file manager) also natively supports vanilla FTP (and WebDAV). It's just not used very often or advertised very broadly, so you may have never come across that...

Nautilus (and possibly Caja too) supports connecting to SFTP and SSHFS just as easily as it supports SMB (or AFP for that matter). So from a user perspective, once it's initially connected and bookmarked, it will act exactly the same. The protocol in use should be completely transparent (and therefore irrelevant) to the user. In fact, you could mount the remote SSHFS fileshare at boot or user login and it would appear as if the files are actually on the local filesystem! (And you could do exactly the same with an SMB share if you wished).

To return to the SMB file manager connection. As I said above, SMB is one of the few protocols where by default the server actively announces itself to the network. As most file managers (i.e. "clients") support SMB, they also "hear" these announcements. That generally means that connecting to a SMB share is really obvious. E.g. in Nautilus, if you go to "Other Locations" you should see any available SMB "domains" (aka Windows Workgroups) and/or SMB servers listed there. So you just need to click them to initiate the connection.

Many other protocols that you can use with Linux don't announce themselves in this same way. You have to actively connect to them and thus know where they are located. So to connect you will need to use a URL which includes the protocol, the specific IP or hostname and the share location. However, once you have connected, then assuming that the IP or hostname doesn't change, you can allow the credentials to be saved and "bookmark" the URL. That makes future connections just as easy as an SMB connection.

As something of an aside, that means that your server should generally be using a static IP. There are ways to work around that (e.g. via "Zeroconf" style network setup) but IMO setting static IPs for "servers" is best practice anyway.

"Cloud stuff"

You also seem to misunderstand what "cloud" actually means. "Cloud" is just a buzzword. It's really just a trendy term for someone else's computer (generally available via the internet and often available to everyone - hence your misunderstanding). So if you run a service on your own computer (i.e. a "server") and don't allow access outside your network (i.e. not available via the internet), then you could consider that as NOT being "cloud stuff". Conversely, you could host an SMB share publicly so it was available via the internet. That could be considered a "Windows cloud share". Note: DON'T ever do that! Unlike protocols like SFTP, SMB is an inherently insecure protocol!

In the case of Nextcloud, IIRC it can also provide access via WebDAV (which Nautilus and probably Caja too support OOTB). Assuming that you don't set up the Nextcloud client software and connect to the files via WebDAV, that may still strictly meet your requirements. So long as you don't have any mobile devices (e.g. laptop, tablet or phone) that need access to the files and are taken offsite, then even with the client apps installed; Nextcloud and Syncthing would both meet your stated requirements.

The nature of these "file sync" applications means that they will have local copies of the files, even if the server is unavailable. If you don't have any devices that go offsite, then the nature of how the file sync works may even make them preferable options!? E.g. the ability to roll back to previous versions of those files could be handy feature.

So what to do?!?

Regardless of all of the above, I'm 99.9% certain that what you want is already possible with your current setup. It seems likely to me that the issue is one of config rather than anything else. I suspect that if you were to adjust your current existing Samba server config and the associated shared file hierarchy appropriately, then it should meet your stated desires (i.e. any user have full access to all files via a single entry point).

Actually, perhaps one of the missing pieces of info for you is that as SMB is not a native Linux protocol, Samba (SMB) users are different to Linux users. So on your server, your Samba (SMB) user(s) need to be mapped to Linux user(s) for the purposes of file access. In effect that means that there are 2 levels of file permissions, the Samba/SMB user level and the Linux user level. FWIW that dual level of permission also exists on Windows, although it's usually hidden by the fact that by default "share permissions" allow everyone and file access is usually controlled at the Windows user permission level.

So as I hinted previously, unless the webUI bundled with TurnKey Fileserver helps you to configure the Samba server setup better, it seems unlikely to me that the TurnKey Fileserver will resolve your issue (at least from the SMB/Samba side of things).

Although it does also have NFS pre-configured. So perhaps NFS might be easier than your previous experiences? But as you'll still need to configure NFS on the guest end (and as you note the guest end of SMB should "just work") I can't guarantee that (plus NFS relies on Linux users on the server which map the to the remote users). If you do try that route, please note that our current Fileserver appliance doesn't include the Webmin NFS config package (see bug #1521 for a workaround).

My recommendation: SSHFS

Essentially SSHFS allows an SFTP share to be mounted locally in the same way that a physical hard drive, USB stick, SD card or CD/DVD can be mounted locally. So whilst technically it does leverage SFTP, it actually works as if the files are local files (it even leverages the FUSE system which is also what USB mounting uses).

Judging from your comments, you don't have any real security requirements (beyond only local access) and don't care about individual user access levels (essentially all PCs and all users have full access to all files). Plus you don't need any access auditing (i.e. you don't need a log of who accessed which file when). Plus you don't have any need to have access to previous versions of files.

Assuming that the above it true, then personally, I'd just use SSHFS. As noted above, SSHFS is a protocol that Nautilus (and likely Caja and other Linux file managers) support OOTB. Although as I also noted above, I'd be inclined to auto mount the SSHFS share(s) either at boot or user login time. Then even your file manager would be unaware that the files are remote. Users would never need to even consider it and the shared files would all appear to be local files. The bonus is that it would also be much more secure than your existing setup! :)

All that this setup would require is an SSH server (e.g. the 'openssh-server' package) installed on your "server" along with a user account which owns the files you wish to share (I suggest not root!). If you configure keypair SSH login access to your server (as the intended user) then no password is required by the PC user. There may need to be some further tweaks to get it working exactly as you want, but it should be a "one off" exercise.

Final word / Summary

Bottom line is that the reason that SMB "just works" between Windows machines is because it's a native proprietary Windows protocol. They've spent a ton of time/money on developing it and streamlining the user experience so that the complexity is hidden and that it "just works" for most users. In my personal experience, despite Microsoft's investment, it still doesn't always "just work" under all circumstance - but YMMV.

If you wish to use SMB between Linux computers, then you need to be aware that you are using a reverse engineered SMB implementation which is never going to be as tailored as the proprietary Windows implementation. It will generally work as desired, but it will require the appropriate configuration.

Ultimately, the "price" you pay is either the Windows licence fee (and associated limitations) or the Samba learning curve and associated complexity (and/or pay a tech that has the knowledge and skills). Implementations such as TurnKey's Fileserver try to make it as easy as possible, but that is essentially just hiding the complexity via a combination of pre-configuration and simplified UI config tools. It doesn't remove the underlying complexity and won't always "just work" under all scenarios.

My suggestions are (not necessarily mutually exclusive and in no particular order):

• Read up on Samba config and try tweaking your existing implementation.
• Have a play with TurnKey Fileserver (I suggest in a VM - at least initially).
• Have a play with SSHFS - this will also likely require some additional reading e.g on SSH keypairs login and associated things (again I suggest in a VM; a TurnKey one or vanilla Ubuntu if that's your preference).
• Hire someone who knows what they are doing to consult, document and/or implement things to your specifications.

Regardless of what you choose to do and how you move forward, I would urge you to carefully document what is done (or if you pay someone, get them to document it so you're not at their mercy). E.g. technologies and resources used, commands run, copies of configuration files, etc. As this stuff is not done regularly, having it documented will make life much easier in the future.

When you document, consider future scenarios such as:

• If/when you may next experience issues with network file sharing or other existing infrastructure, including disaster recovery.
• Your business changes and you need to adjust the way that files are organised and/or who has access to which files.
• You replace a staff member or bring on an additional new one.
• You add or replace a server or PC.

I hope I haven't daunted you too much and more than happy to share more thoughts if you need clarification

Reading your response to my essay almost makes me cringe a little! :) Your response is pretty gracious considering that I essentially tried to teach your grandma to suck eggs...

I'm glad that it was of value...

I'll try to not add too much more to my previous tome, but I can certainly help a little with your Ubuntu vs TurnKey understanding. Obviously I'm a little biased and opinionated, so YMMV.

Firstly, TurnKey is based on Debian (v16.x = Debian 10/Buster under the hood). We provide a library of ~100 minimalist, purpose built "software appliances". As a general rule, each one is trying to fulfil a specific function and/or provide a specific piece of software (and all it's dependencies). The philosophy is that we're trying to make more open source software more accessible to more people.

We use custom, internally developed build infrastructure to build our appliances. We package our build tools as an appliance of it's own; known as TKLDev. All our appliance build code is published on GitHub. The appliances are built from a combination of packages, overlaid files and configuration scripts. The packages are mostly from Debian, plus some custom packages we provide and some particular appliances also install specific software via third party apt repos. The overlays are generally scripts and/or complete config files.

We don't claim (or even aim) to be everything to everyone. But we do aim to provide off-the-shelf products which will be useful as-is to the uninitiated; but simultaneously provide a "better" starting place (in comparison to a vanilla OS) for those more knowledgeable. We probably don't achieve the latter as much as we'd like, although I think we do ok (we have quite a few "IT consultants" among our customers).

Our base appliance (essentially what all others are based on) is called Core. Despite our aim to be minimalist, Core (and therefore the whole library) does include a few pieces of software aimed at trying to be more user friendly. E.g. we package and pre-install Webmin as well as a few other bits and pieces (e.g. Postfix for sending emails)...

Re Ubuntu vs Debian, unless you are in the market for paid support (and even then...) when it comes to servers, personally I think using Debian is a no brainer. My personal experiences have been that Debian is more stable and secure (Ubuntu only guarantee timely security updates to their "main" repo; Debian provides security updates for almost all of the packages available).

Re Desktops, I personally run Debian there too, but I understand those that don't. Debian doesn't release as often, so the software can get more dated than Ubuntu. Although on the upside, I have generally found Debian generally much less buggy than Ubuntu. They call it "stable" for a reason! :)

Debian online documentation is not quite as polished or complete as Ubuntu (although it is getting better IMO) and mostly Ubuntu docs apply to Debian anyway (except if they are recommending installing via a 3rd party repo).

Ubuntu too is based on Debian, but unlike us, they start with a snapshot of Debian "unstable" (we base directly on Debian "stable" - I assume this is part of the reason that Debian tends to be less buggy than Ubuntu). Also unlike us, Ubuntu import the source code and recompile everything themselves, plus add a few programs themselves and maintain their own set of kernel patches (we install most of the OS direct from Debian repos). As such Ubuntu cannot be considered binary compatible with Debian. So generally you shouldn't ever install Ubuntu packages on Debian (or TurnKey) - they will often work fine, but at some point you will encounter packages that will break things and you will have a very bad day...!

It's also worth noting that whilst TurnKey can install to bare metal, you'll find that it doesn't support anywhere near as much hardware OOTB (especially compared to Ubuntu) and it's more often used as a VM.

FWIW my knowledge tends to be broad rather than deep, but I do know TurnKey intimately even if my knowledge of the usage of some of the software is pretty basic. I also have at least basic knowledge of many things Linux and my google-fu is pretty darn good! :)

Anyway, I've done it again (written way more than I intended)... If yo have any specific questions (or even ideas/feedback) please feel free to post back. If you do end up trying TurnKey, I'd certainly love to get your feedback.

TBH, I have very little experience with Samba and zero using the GUI (my past Samba setups have been with manually editing the smb.conf file and/or using Webmin (web based UI that is packaged in TurnKey).

But since I don't have any Windows PCs on my network anymore, I haven't played with it for years.

Re Desktop, I use Debian and run Gnome3. I didn't like it initially (I was a big fan of Gnome2 back in the day) but stuck with it (mostly because I'm lazy and couldn't be bothered spending time trying to reconfigure it). I used Mate relatively recently and wondered why the hell I ever preferred Gnome2 over Gnome3! After getting used to using Gnome3 navigating through all those menus was such a drag... Everything is at my fingertips with Gnome3 (whether I'm using the mouse or the keyboard). I mean obviously I could have set up keyboard shortcuts for Mate 2 if I wished, but Gnome3 "just works" and works so well... My 2c anyway...

And also I must admit that I'm surprised that none of the tutorials you used mentioned 'nofail'. IMO it's also good practice to double check an updated fstab by manually unmounting the updated/new filesystem(s) and then manually running 'mount -a'. Any interaction required will be a deal breaker (as you're now well aware...).

Also with in being a network dependant filesystem, I do vaguely recall that there is an option for explicitly requiring it to wait for that in the fstab. But it's not in the fstab man page and google isn't helping ATM...

Although, these days, in the case of a network dependant filesystem, I'd almost be inclined to not bother with the fstab and do the mount via a systemd '.mount' file. Leveraging systemd to do the mount would allow you to make it 'after=network-online.target' to ensure that it doesn't even try to mount until the networking is set up.

So long as you have the keys set up (which I thought I did mention?!) then one easy way to do the mount that would be reliable would be to run it at login.

To set up the keys (logged in as the user who will have the auto login and assuming that you have already generated a key for the user):

ssh-copy-id user@xxx.xxx.xxx.xxx

(Where xxx.xxx.xxx.xxx is the FQDN or IP of the server).

Then (assuming that Ubuntu sets it up the same as TurnKey?!) an executable bash script that mounts the remote share could be dropped into ~/.profile.d/. Then the filesystem should be auto mounted on every log in. If you want it to happen for all users, then you could put it in /etc/profile.d/ instead. However, you'll need to either use a shared key (and explictly use that key in the sshfs command) that has already been added to the server, or ensure that all users have their keys copied to the server ahead of time. If you forget then you'll hit that issue again.

As a failsafe it's probably also worth adding a time out, so worst case scenario it takes ages to log in (and the remote filesystem isn't mounted), rather than becoming a new drama just because the server isn't running for some reason (or someone pulled a netwokr cable, or whatever).

As per my 'option 2' above, my inclination would be to make a script and drop it straight into one of the profile.d directories (either system wide, or individual depending on your use case and/or preference).

If that doesn't work as expected, then fix that so that it does (I'm happy to point out how if that's the case).

Alternatively (perhaps as an intermediate step?), you could just create a standalone bash script (not in profile.d) to run your 4 commands. Essentially creating a new single command that will run your 4 commands. You could then setup the automation (i.e. profile.d) as a separate step (and instead of the whole script in that file, point it to this script you've made).

You could no doubt do this via some GUI app, but IMO it's easier to use the terminal. Assuming you're running as a sudo user and you're happy to use nano (personally I'm a vim user, but nano is easy to use for the uninitiated):

sudo nano /usr/local/bin/mount-sshfs

Note that as per the FHS (File Hierarchy Standard) /usr/local/bin is a good place to put executable local system scripts generated and maintained by you. The location should already be in your PATH (i.e. so once we're done, this script should just work when you type 'mount-sshfs'). If it's not, that's easy to fix too, but lets cross that bridge if we get to it...

The first line needs to be a shebang (the first line so the system knows it's a bash script) and then just add your 4 commands on separate lines. E.g. so it looks something like this (note the '-e' is good bash script practice so that the script will exit if one of the commands fails):

#!/bin/bash -e

COMMAND_1
COMMAND_2
COMMAND_3
COMMAND_4

Save and exit, then make it executable:

sudo chmod +x /usr/local/bin/mount-sshfs

Now to test, try running it:

mount-sshfs

Hopefully it "just works"...

If you haven't already set up keys, I would strongly reommend that, as then there will be no need for it to be interactive (which will save headaches later if/when you automate it).

IMO keys and a simple profile script is the easy answer and would take less than 2 minutes...

sudo ssh-keygen -N '' -f /etc/keyfile
sudo ssh-copy-id -i /etc/keyfile.pub USER@REMOTE_HOST

Follow the prompts, including logging in via password. Then double check the passwordless connection via SSH:

ssh -i /etc/keyfile USER@REMOTE_HOST

(Then exit assuming that it works).

Then mount the remote filesystem (with no password required) like this:

sshfs USER@REMOTE_HOST:/remote/path /local/path/ -o IdentityFile=/etc/keyfile

But it's your system you do what works for you... ;)