CIFS mounts and Kerberos - permissions on access or best practice
Use automount + multiuser option of mount.cifs
You can achieve this using automount and the multiuser option for mount.cifs. Install the required packages:
sudo apt install autofs keyutils cifs-utils
The following example assumes that the cifs server exports a share that is named after the user that is accessing it. Normally that would be suitable for home directories.
Add this to your /etc/auto.master
:
/cifs /etc/auto.cifs
In /etc/auto.cifs
put this:
* -fstype=cifs,multiuser,cruid=${UID},sec=krb5 ://server.domain/&
Make sure to replace server.domain by your file server. You could also use a fixed share this way. Just replace the *
by a fixed name and also the &
.
An important detail in the above configuration is the cruid=${UID}
. It will make the kernel look for a kerberos ticket in the context of the user accessing the share. Otherwise it would be trying roots ticket cache.
Finally reload automount:
sudo service autofs reload
If you have a kerberos ticket, it will mount the file system /cifs/$USER
on first access. That means you need to explicitly type e. g. cd /cifs/myuser
or a similar action in a GUI file browser. To avoid this you could place symbolic links pointing to this from somewhere else and tell users to access those.
If you are using a fixed share (not using *
and &
) of course you would have to type cd /cifs/sharename
.
Subsequent access by other users to the same share will be using their permissions, made possible by the multiuser
option. No additional mount will be made but the existing one reused.
From mount.cifs(8):
multiuser Map user accesses to individual credentials when accessing the server. By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. With this option, the client instead creates a new session with the server using the user's credentials whenever a new user accesses the mount. Further accesses by that user will also use those credentials. Because the kernel cannot prompt for passwords, multiuser mounts are limited to mounts using sec= options that don't require passwords.
It is also possible to add the required automount maps to an LDAP server for central management, but this is probably beyond the scope of this answer.
In your question you asked for the mount to be mounted as root on boot. Technically this is done here in form of a place holder mount for autofs. Practically the real mount is only done on first access by a user.
We are using this setup for ~100 clients at my workplace for accessing quite a big lustre file system and it works reliably.
user2149308
Updated on September 18, 2022Comments
-
user2149308 over 1 year
Currently our Ubuntu-Clients connect to cifs shares during system boot via /etc/fstab. This has the following disadvantages:
- Passwords are written in plain text as mount option
- The password should expire, but if it does, the /etc/fstab has to be changed on every client. So most passwords used for mounts simply don't expire at the moment
- The CIFS share is mounted under the connecting user and his permissions, so the user actually working with the share on Ubuntu is not displayed. A side effect is a blur of permissions, because the Ubuntu-users are not listed in the Windows file system permissions.
What I already successfully tested on our Ubuntu-Clients: Using kerberos authentication on user login - so there is a kerberos ticket available for the user.
Using that kerberos ticket to (sudo) mount the cifs share within a systemd userservice
- PRO: Works on graphical login as well as ssh
- PRO: Share is accessible like the local file system
- CON: If I mount on a global mountpoint like /servers/mymount, I have to take care, that I don't overlay mounts by multile users. And the connecting user then would be the one who's permissions would be used by any following user.
Using that kerberos ticket to dynamically mount the share from the file browsers nautilus and thunar
- PRO: If the connection to the share is established via file browser, no extra script or service is necessary
- PRO: The share is mounted into the user context, so definitely with the users permission. If the user has no permission, there is still the possibility to connect the share with another user.
- PRO: The mounts could be automated by /etc/profile using gvfs-mount
- PRO: No sudo-rights are neccessary, the user can gvfs-mount and -unmount as he wishes, very intuitive via file browser
- CON: There is no actual mountpoint, standard unix commands like ls, cp and so on don't work. I would have to use gvfs-* alternatives. At this point the above solution with mount.cifs appears to be better.
So what I would like is to access the cifs share like I access an nfs share.
- No passwords used during the mount
- The permissions of the accessing user should be used
- The filesystem should behave like the local file system (standard unix commands should work)
I could mount a CIFS share multiple times, separately for each user into his home directory, but
Is there a way to mount the CIFS share during boot by the user root, not specifying a connecting user and then using the permissions from an accessing user (for example via kerberos ticket)?
Thank you in advance, Bastian
-
user2149308 about 6 yearsNo, definitely not. That is exactly what I am looking for. I just wanted to run some tests before I accepted the answer - which I couldn't, because I was busy otherwise. I will update this thread soon and post my final solution here.
-
user2149308 about 6 yearsOkay, so that solution works great for global mountpoints. To use absolute paths in
/etc/auto.cifs
, I edited your enty in the/etc/auto.master
to/- /etc/auto.cifs --timeout=1
, as documented here. Which brings me to two parameters I experimented with: --timeout=<x seconds> (the share is disconnected after <x seconds> without access) and negative_timeout=1 (after a failed mount request wait <x seconds> until allowing a retry). The latter I set in/etc/autofs.conf
-
user2149308 about 6 yearsWhat did not work, was to automatically mount into the users home directory, because no variables could be specified in the first column of
/etc/auto.cifs
. Maybe this could be achieved by using a script instead of a text file, but I already have a working mechanism in place for that scenario: systemd usershare + sudo mount (with multiuser option, thanks again for that hint!). The major disadvantage of that approach regards global shares, so it doesn't apply here. -
Sebastian Stark about 6 yearsI don't quite understand. Why you could not use "/home /etc/auto.cifs" in auto.master? It should mount user homes from //server/user
-
user2149308 about 6 yearsI think you assume that the cifs share contains the home directories, but thats not the case. The home directories are mounted via NFS on /home. Additionally to these Linux home direcories, every user has a Windows home directory. I want to mount that one as part of the Linux home directory: /home (NFS mount), /home/<user> (Linux home), /home/<user>/win_home (Subdirectory of Linux home). So with the suggestion you commented I wouldn't see my Linux homes anymore and with the suggestion you posted initially they would be located under /cifs/<user> - not as part of the Linux home.
-
user2149308 about 6 yearsThe file system rights would be correct, but - logically - doesn't personal data (like the Windows home) belong in the (Linux) home directory?
-
Sebastian Stark about 6 yearsI now understand. But it shouldn't matter too much where they are mounted, you could just place a symlink in the users home, no? For the user doesn't make a big difference.
-
Sebastian Stark about 6 yearsIn our workplace all (except home) of the available shares, personal or not, are outside the home. Users who need them can symlink them. If only GUI access is important and that submount happens to be one of Desktop/Downloads/Templates/Public/Documents/Music/Pictures/Videos you could also use /etc/xdg/user-dirs.conf.
-
Sebastian Stark about 6 yearssomething that speaks against putting any mounts into the users home (symlinked or directly) is that in case of unreachable server for the submount they will not be able to do much anymore since any attempt to list files in their home will lead to hanging shell or errors. But I think this is a bit beyond the scope of your original question and my answer to it.
-
Auspex over 5 yearsAwesome answer! I'm a bit surprised more people haven't upvoted it. I've been using pam_mount, but occasionally I lose my mounts and
autofs
seems more robust -
Sebastian Stark over 5 years@Auspex I guess it's a little "special interest" :)
-
Auspex over 5 years@SebastianStark It is, but I'd argue that it's a "special interest" that practically everybody on AskUbuntu is going to run into sooner or later. It's a pretty small pool of users that never have to talk to a Windows server :-(