0

I've inherited an Ubuntu 14 Fileserver...

VERSION="14.04.5 LTS, Trusty Tahr"

Client machine is a fresh install of Ubuntu 18

VERSION="18.04.2 LTS (Bionic Beaver)"<br>
autofs/bionic-updates,now 5.1.2-1ubuntu3.1 amd64 [installed]<br>

We are in a Samba Active Directory (AD) domain...

(Samba server)VERSION="14.04.5 LTS, Trusty Tahr"
(Samba)Version 4.3.11-Ubuntu

I've configured a test SMB mount using autofs. When I try to access the share as the owner "UserName" (a Samba Active Directory domain user) it tries to mount, but fails (see error below).

I am able to mount the share manually at the command line.

root@LocalComputer:/mnt# sudo mount -t cifs -o rw,user=UserName,domain=DomainName  \\\\ShareServer\\testshare /mnt/test/
Password for UserName@\ShareServer\testshare:  *****************
root@LocalComputer:/mnt# cd test
root@LocalComputer:/mnt/test# ls -la
total 0
drwxr-xr-x 2 root root 0 Mai 23 13:35 .
drwxr-xr-x 3 root root 0 Mai 24 15:49 ..
drwxr-xr-x 2 root root 0 Mai 24 12:39 UserName

...but unable from autofs...

UserName@LocalComputer:/mnt$ cd test/
-bash: cd: test/: No such file or directory
UserName@LocalComputer:/mnt$ 

kerberos seems ok on the server...

root@LocalComputer:/mnt# kinit -l 10h -r 5d UserName
Password for UserName@DomainName:*****************

root@LocalComputer:/mnt# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: UserName@DomainName

Valid starting       Expires              Service principal
24.05.2019 16:19:00  25.05.2019 02:18:54  krbtgt/DomainName@DomainName
    renew until 29.05.2019 16:18:54

What do I do to allow this user to automount the share, using authentication provided by the AD? Is this related to the user=root in the error log?

ERROR from syslog

May 24 15:41:29 LocalComputer kernel: [ 3051.503993] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
May 24 15:41:29 LocalComputer cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=ShareServer.itec.uni-karlsruhe.de;ip4=xxx.xxx.xx9.10;sec=krb5;uid=0x0;creduid=0x1f420;user=root;pid=0x9e8
May 24 15:41:29 LocalComputer cifs.upcall: ver=2
May 24 15:41:29 LocalComputer cifs.upcall: host=ShareServer.itec.uni-karlsruhe.de
May 24 15:41:29 LocalComputer cifs.upcall: ip=xxx.xxx.xx9.10
May 24 15:41:29 LocalComputer cifs.upcall: sec=1
May 24 15:41:29 LocalComputer cifs.upcall: uid=0
May 24 15:41:29 LocalComputer cifs.upcall: creduid=123456
May 24 15:41:29 LocalComputer cifs.upcall: user=root
May 24 15:41:29 LocalComputer cifs.upcall: pid=2536
May 24 15:41:29 LocalComputer cifs.upcall: get_cachename_from_process_env: pathname=/proc/2536/environ
May 24 15:41:29 LocalComputer cifs.upcall: unable to init krb5 context: 13
May 24 15:41:29 LocalComputer kernel: [ 3051.567301] CIFS VFS: Send error in SessSetup = -126
May 24 15:41:29 LocalComputer kernel: [ 3051.567318] CIFS VFS: cifs_mount failed w/return code = -126
May 24 15:41:29 LocalComputer cifs.upcall: Exit status 1

/etc/auto.master

+dir:/etc/auto.master.d
+auto.master
/mnt /etc/auto.cifs

/etc/auto.cifs

test   -fstype=cifs,multiuser,cruid=${UID},sec=krb5  ://ShareServer.DomainName/testshare

autofs starts OK

May 24 16:27:23 LocalComputer systemd[1]: Stopping Automounts filesystems on demand...
May 24 16:27:24 LocalComputer automount[2875]: umount_autofs_indirect: ask umount returned busy /mnt
May 24 16:27:25 LocalComputer systemd[1]: Stopped Automounts filesystems on demand.
May 24 16:27:25 LocalComputer systemd[1]: Starting Automounts filesystems on demand...
May 24 16:27:25 LocalComputer systemd[1]: Started Automounts filesystems on demand.
1

1 Answer 1

3

I have a similar setup. We have for decades been using autofs default behaviour via

/net -hosts

in /etc/auto.master to mount our NFS shares.

Now, we already have AD authentication and kerberos tickets are being issued on login.

So we wanted similar action for SMB/CIFS shares, without any complications.

For me, the changes I had to do was to change file /etc/auto.smb (or auto.cifs):

get_krb5_cache() {
    cache=
    uid=$UID

to

get_krb5_cache() {
    cache=
    uid=$AUTOFS_UID

It turns out that autofs has its own set of env. vars. , and when uid=$UID it (in my case at least) always used kerberos ticket /tmp/krb5cc_0 - where 0 is uid of root, not the user trying to mount via autofs. After altering the env to AUTOFS_UID, autofs got the user's uid, found the users krb ticket and mount was successful.

So: It boils down to 2 steps (and I repeat: In my case!)

Step 1:

Add this line to /etc/auto.master:

/cifs   /etc/auto.smb --timeout=60

This means that autofs will mount each smb/cifs server as /cifs/hostname and there under /cifs/hostname/sharename

Step 2:

Alter uid=$UID to uid=AUTOFS_UID in /etc/auto.smb (or /etc/auto.cifs) as showed above.

Now this works much in the same fashion as NFS via /net -hosts

After making these changes I can do

cd /cifs/smb-server-1/share-1

And even using /cifs/smb-server/staff/ as /home/ (via symlinks) works seamlessly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .