В теме https://forum.altlinux.org/index.php?topic=32361.msg311768#msg311768 у Вас сказано:
p9/branch
В thunar на p9/branch протокол smb поддерживается, но доступ к samba шарам через Обзор сети thunar сломан.
Я так понимаю ЭТО уже исправлено?
Нет. Не исправлено.
Теоретически, это можно обойти закатом солнца вручную.
Часов 5-6 убил на то, чтобы докопаться, почему в установленной p9-xfce-sysv шара с самба-сервера на p7-sysv-tde видна, а в свежем лайве p9-xfce-sysv-20201212, thunar валит пустое окно. И что такого накрутил в установленной, что доступ к шаре есть. А с момента установки прошло месяцев десять.
Говорят что связано с устаревшим протоколом. Фигня это всё. Это можно обойти.
Но лучше по-порядку:
При попытке получить доступ к самба шаре в thunar через Обзор сети, если thunar отображает пустое окно, значит самба-сервер в сети, но thunar не может отобразить, ни самба-шару, ни сервер, ни группу.
Если самба-сервер выключен и недоступен, thunar вывалит окно с ошибкой.
Эту линуксовую заморочку нужно просечь и запомнить. Это важный момент.
Решение так близко, что дойти до него можно не сразу.
Теперь следите за руками:
samba-client, который в p9-xfce-sysv, по зависимостям тащит samba-common-tools
# apt-cache depends samba-client | grep samba
samba-client-4.12.10-alt2:p9+260060.144.9.2@1606247724
Требует: samba-common-tools = 4.12.10-alt2:p9+260060.144.9.2
Вытесняет: <samba-client-cups>
Тот в свою очередь притащит samba-common
# apt-cache depends samba-common-tools | grep samba
samba-common-tools-4.12.10-alt2:p9+260060.144.9.2@1606247724
Требует: samba-common = 4.12.10-alt2:p9+260060.144.9.2
Требует: samba-common-libs = 4.12.10-alt2:p9+260060.144.9.2
Вытесняет: <samba-DC-common-tools>
А сам samba-client, тащит gvfs-backend-smb
# apt-cache rdepends samba-client
samba-client
Reverse Depends:
gvfs-backend-smb
А smb.conf лежит на стороне самба-клиента
# rpm -ql samba-common | grep smb.conf
/etc/samba/smb.conf
/usr/share/man/man5/smb.conf.5.xz
Так в чём фишка? А фишка в том, что сервер и клиент должны быть в одной группе.
Т.е.:
По-умолчанию это группа MYGROUP прописанная в smb.conf на стороне клиента:
# grep workgroup /etc/samba/smb.conf
# workgroup = NT-Domain-Name or Workgroup-Name, eg: MIDEARTH
# workgroup = MYGROUP
workgroup = WORKGROUP
И группу на клиенте в серверном конфигурационном файле, нужно сменить на ту, которая прописана в smb.conf сервера.
Если группа на клиенте будет отличаться от той которая прописана на сервере, то на Обзор сети thunar вывалит пустое окно.
Теперь снова вернёмся к thunar.
Выстраивается цепочка на клиенте:
thunar => gvfs-backend-smb => ... => smb.conf
Штука в том, что при открытии X-сессии пользователя, thunar запускается демоном. И чтобы изменение в клиентском серверном smb.conf подхватились (какой каламбур), нужно или перезапустить демон thunar -а или перелогиниться в X-сессию.
Всё идёт хорошо до тех пор, пока в сети не появится другой самба-сервер с другой группой. В этом случае всю эту эквилибристику на стороне клиента надо будет повторить.
Попутно несколько моментов:
smbtree не покажет ни сервер, ни шару.
Сервер покажет findsmb:
$ findsmb
*=DMB
+=LMB
IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION
---------------------------------------------------------------------
IP-адрес ИМЯ-ВСЕТИ +[ РАБОЧАЯГРУППА ]
smbclient в свою очередь подскажет почему не отобразилась рабочая группа:
$ smbclient -L NETBIOS-NAME
Enter WORKGROUP\altlinux's password:
Sharename Type Comment
--------- ---- -------
homes Disk
multimedia Disk Video-Audio
IPC$ IPC IPC Service (Samba Server Version 4.5.12)
SMB1 disabled -- no workgroup available
Если в сети всё ещё используется Windows, то в ней протоколы SMBv1/v2/v3
можно обнаружить, включить или отключить. Любой и на выбор.
Хотите, играйтесь ещё с протоколами:
https://phabricator.kde.org/D18878#408714Развлекайтесь в общем.
