How to mount NAS for multiple users

General system Newbie
1

Hi there,

I am currently struggeling with mounting my NAS shares in EOS. I found various resource explaining the process in general, but I am missing one key feature: How do I get it to work properly for multiple users on the client side with potentially different permissions on the NAS side? This is the point, which I miss in almost all of the explanations.

Where am I coming from: Windows. There each user can mount the shares as network drives via SMB. Each users can have its own setup, passwords are stored and connections work magically (automatically mounted on boot, automatically mounted when NAS is switched on and the Client-PC was already running). The NAS should be aware of the permissions of each user and also should set e.g. the correct owner of the files.

How would I replicate this as close as possible on EOS?

The NAS is a Synology by the way.

First questions is SMB or NFS. Currently I focus on SMB, because this is the current setup I have already on the NAS side. But I could imagine to switch over to NFS, if this is more feasible in general.

I started my journey in the Arch-Wiki: https://wiki.archlinux.org/title/Samba#Client. However, the solutions proposed seem only to work for a single user, if I understand it correctly. I could store each users credentials in different files and add the mounts to fstab, but this would also mean that the same share is mounted separately for each user. I could maybe work around this by mounting the shares in each users home directory. This does not feel ideal, but could work. I also imagine that this would mean that the NAS thinks that all users made a connection at the same time. Which is not horrible, but adds noise.

I also looked briefly at the following thread and the corresponding Arch-Wiki: Automatically mount NAS folders using NFS This seems to look similar. But I did not yet get into the weeds of NFS. But maybe this would be the right choice?

The following describes a way to make mounting easier without sudo: https://help.ubuntu.com/community/Samba/SambaClientGuide. This could be a way for manual mounting by each user. But I would prefer automatic mounting.

Then I came across multiuser mounts via the following two links:

This sounds very promising. But I have no idea about Kerberos and NTLM. Before I go deeper into that rabbit hole, I thought to double check the approach here. Maybe there is overall a simpler approach to my problem. And as I start to get confused with all the various options (NFS/SMB, fstab/systemd-mount-unit, own scripts, multiuser-mounts, …) I would appreciate some help pointing me in the right direction.

Thank you very much in advance.

P.S.: I am using KDE. Mounting in Dolphin seems to work as I like it. But I would require a proper path to the share, which would allow me to do rsync operations and even provide the share to a program running in Wine.

2

I’ve managed this issue by having a script available on each user’s desktop, that they run (double-click) to mount the NAS.

My script does 4 things (but these are mostly optional):

  1. Tests the NAS is online, otherwise the script exits.
  2. Unmounts any existing mount, in case another user already mounted the NAS.
  3. Mounts the NAS shares for this user.
  4. Performs some file synchronisation between NAS and PC (wallpapers, music etc).

I’m using a Synology NAS too, but I’m using SFTP, not SMB or NFS, so I’m not sure how helpful a glimpse at my script would be for you. Of the three, SFTP is the most secure method of communication with the NAS. You can use it from Dolphin (sftp://somenas), provided you’ve set up your SSH keys correctly (where it gets a little complicated). It’s mounted using sshfs.

3

:exploding_head:

one more option to think about.

Just kidding. Thanks for the idea. sshfs could also be an idea. I will take brief look into this as well. My gut feeling leans more towards SMB or NFS.

1 Like
4

Yeah, I will admit, most people seem to lean towards SMB and NFS, even when I’ve done the big sell :sweat_smile:

That’s perfectly fine, and the above script idea would still be applicable, it’d just be using different commands to those I’ve used.

5

One “issue” with your approach is, that it does not allow to have two users work simultaneously - which would be a very specific edge case. But I think this won’t apply to my setup, but could be interesting for a server or virtual machine.

6

I suspect multiple simultaneous accounts are possible.

When using the sshfs command to mount the SFTP shares, a user is specified per mount:

sshfs bink@mynas:/home /home/bink/MyNAS/Home -o compression=no -o cache=yes -o kernel_cache

It’ll reference the ~/.ssh/config file for the configuration details of connecting to mynas, such as the user-specific security certificate.

Presumably I could also set up another connection for a different user, by providing a different SSH config file to reference:

sshfs retnug@mynas:/home /home/bink/MyNAS/RetnugHome -o compression=no -o cache=yes -o kernel_cache -F ~/.ssh/config-retnug

If using Dolphin to directly connect (not mounted), you’d specify the user in the address bar:

image

If you have a certificate defined in your ~/.ssh/config for that connection, you won’t need to specify a password in the address there. But using a password (and assuming password based auth is enabled on your NAS’s SFTP), you could connect as different users this way I presume.

7

Is that what you meant by two users working simultaneously?

Just to clarify, if the users are connecting from a different system, whether it’s another PC, or a VM, there’s no issue with that. Multiple systems are accessing my NAS via SFTP simultaneously, as different users.

8

It think this is closely what I meant. Simultaneous connections from different clients works of course. I was concerned about connections from the same client machine but from different users (e.g. one logged in on the physical machine and someone else via ssh on the client and then mounting the NAS on the client). This setup is also very easy when mounting different directories as in your example above. More interesting is, when they use the same share on the NAS. But this would also work if it is then mounted in different paths on the Client. I mainly stumbled over your second point in the description above: “Unmounts any existing mount, in case another user already mounted the NAS.”

1 Like
9

Ah fair enough. It’s just the way I’ve chosen to handle it, as when switching between user accounts, it simply unmounts / remounts the shares to ensure they’re being access by the currently logged-in user.

I’ve not personally needed to provide access to two different user accounts on the NAS, from a single desktop session, but if you and others share a generic desktop login, I can understand why that could be helpful.

10

My 2 cents about SMB vs NFS (after working with a bunch of NASes at home):

  • With SMB, authentication is via symbolic user name and password. The files will be handled by the NAS according to Windows permission system (though the NAS itself is Linux). Thus, NAS user IDs and your PC user IDs don’t have to match.
  • With NFS, “authentication” is via hostname / IP address. The files are handled according to Linux rules (unless you “squash” every user to some specific NAS user). In this case, user IDs (numeric IDs, not symbolic names) on the NAS and on the PC should match, or else…

In my case, I ended up squashing all NFS accesses to “guest” (the stuff is intended to be shareable) and set a couple of shares with my private stuff to be accessible only from my own laptop.

11

Thanks for the explanations. The NFS part is similar to my knowledge and is one reason why I hesitate to use it. I cannot imagine to reliably ensure matching of user IDs over multiple systems (NAS, Computer A, Computer B, etc.), because each machine could have a different set of users. And as some people share the same client computer, but have different access rights on the NAS, it is not feasible - in my opinion - to define access rights on a client machine level.

This thinking - which might be wrong - along with the need to allow also Windows clients access to my NAS, currently brings me more towards SMB/CIFS as most favored solution. (I currently cannot yet assess whether the SFTP/SSHFS approach of blink would work well with Windows clients, but they could use SMB in parallel - which would also work when using NFS, now that I have written it)

1 Like
12

If you’re serving Windows clients, that’s a compelling reason to focus on SMB/CIFS.

13

Yep, you’ll need to bring up some kind of LDAP server to solve this. More headache…

14

@retnug, is this for your home network, or are you setting up a college/corporate network?

An LDAP server + Samba is something I’ve used on a college network to serve Windows clients. But I suspect it might be overkill for the home network.

Just taking a step back for a moment, can you describe a typical scenario? Is it one desktop-login per user? Do you have control over setting both usernames and passwords for users?

If so, so long as your desktop usernames and passwords match those on the NAS, when the user logs in, they can access the NAS as that user. In simpler scenarios, this is a super simple way of handling users, without needing to mess about with LDAP.

So if my desktop username is bink with the password frillypinkones, I’d need to ensure the NAS has a matching user added with the username bink and password frillypinkones. On the NAS, I’d also need to ensure that user belongs to groups that have access to shares on the NAS.

Then from the desktop, when accessing the NAS shares, those credentials are automatically forwarded and authenticated.

1 Like