Я унаследовал файловый сервер Ubuntu 14 ...
VERSION="14.04.5 LTS, Trusty Tahr"
Клиентская машина - это свежая установка Ubuntu 18
VERSION="18.04.2 LTS (Bionic Beaver)"<br>
autofs/bionic-updates,now 5.1.2-1ubuntu3.1 amd64 [installed]<br>
Мы находимся в домене Samba Active Directory (AD) ...
(Samba server)VERSION="14.04.5 LTS, Trusty Tahr"
(Samba)Version 4.3.11-Ubuntu
Я настроил тестовое крепление SMB, используя autofs. Когда я пытаюсь получить доступ к общему ресурсу как владелец «UserName» (пользователь домена Samba Active Directory), он пытается подключиться, но терпит неудачу (см. Ошибку ниже).
я могу установить долю вручную в командной строке.
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
... но не может autofs...
UserName@LocalComputer:/mnt$ cd test/
-bash: cd: test/: No such file or directory
UserName@LocalComputer:/mnt$
Kerberos вроде нормально работает на сервере ...
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
Что мне сделать, чтобы разрешить этому пользователю автоматически подключать общий ресурс, используя аутентификацию, предоставляемую AD? Связано ли это с user=root в журнале ошибок?
ОШИБКА из системного журнала
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 запускается нормально
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.
У меня аналогичная установка. На протяжении десятилетий мы использовали поведение autofs по умолчанию через
/net -hosts
в /etc/auto.master, чтобы смонтировать наши общие ресурсы NFS.
Теперь у нас уже есть аутентификация AD, и билеты Kerberos выдаются при входе в систему.
Таким образом, мы хотели аналогичное действие для общих ресурсов SMB / CIFS без каких-либо осложнений.
Для меня изменения, которые мне нужно было сделать, это изменить файл /etc/auto.smb (или auto.cifs):
get_krb5_cache() {
cache=
uid=$UID
к
get_krb5_cache() {
cache=
uid=$AUTOFS_UID
Оказывается, у autofs есть свой набор env. вары. , и когда uid = $ UID, он (по крайней мере, в моем случае) всегда использовал билет kerberos / tmp / krb5cc_0 - где 0 - это uid пользователя root, а не пользователь, пытающийся смонтировать через autofs. После изменения env на AUTOFS_UID, autofs получил uid пользователя, обнаружил билет krb пользователя и монтирование прошло успешно.
Итак: это сводится к 2 шагам (и я повторяю: в моем случае!)
Шаг 1:
Добавьте эту строку в /etc/auto.master:
/cifs /etc/auto.smb --timeout=60
Это означает, что autofs будет монтировать каждый сервер smb / cifs как / cifs / hostname и там в / cifs / hostname / sharename
Шаг 2:
Измените uid = $ UID на uid = AUTOFS_UID в /etc/auto.smb (или /etc/auto.cifs), как показано выше.
Теперь это работает так же, как NFS через / net -hosts.
После внесения этих изменений я могу сделать
cd / cifs / smb-server-1 / share-1
И даже использование / cifs / smb-server / staff / as / home / (через символические ссылки) работает без проблем.