Подключенная домашняя папка ecryptfs «исчезает», когда Samba закрывает сеанс для моего (интерактивного )пользователя через PAM

Ну, это, конечно, глупо, так как всего несколько часов назад я «потратил» 200 очков репутации на награду, но, похоже, я разгадал загадку.Любой, кто подскажет, на что обратить внимание и попробовать, что проще, чем у меня, получит награду.

Итак, оказалось, что pam_unixиз журналов был важной подсказкой. В итоге мне удалось спровоцировать ситуацию и тем самым надежно воспроизвести размонтирование.

То, что я сделал, также описано в соответствующей заявке на launchpad.net , но я воспроизведу здесь соответствующие части, которых нет в вопросе выше.

Мойsmb.confдо того, как я копался в этой проблеме, выглядел так, как показано в выводе testparm:

# Global parameters
[global]
debug uid = Yes
dns proxy = No
guest account = johndoe
log file = /var/log/samba/log.%m
map to guest = Bad Password
max log size = 1000
obey pam restrictions = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully*.
passwd program = /usr/bin/passwd %u
security = USER
server role = standalone server
server string = %h server (Samba, Ubuntu)
syslog = 7
syslog only = Yes
workgroup = NULL
idmap config * : backend = tdb

[sharename]
force create mode = 0660
force directory mode = 0770
guest ok = Yes
guest only = Yes
path = /data/sharedir
read only = No

Я выбрал своего рода -метод проб и ошибок. В Tmux у меня было открыто несколько панелей, когда я пытался создать MWE для отчета о дефекте. Именно этим я и занимался :

1. while mountpoint /home/johndoe; do sudo service smbd restart; date; sleep 2s ; done
2. watch 'mount|grep ecryptfs'
3. sudo tail -F /var/log/auth.log|grep samba:session

... в другом окне Tmux я отредактировал/сохранил /etc/samba/smb.conf.

Взрыв!

В auth.logпоявилась запись в журнале (smbd[144802]: pam_unix(samba:session): session closed for user johndoe), а точка монтирования исчезла.

Наконец-то я нашел способ воспроизвести раздражающее состояние.

Учитывая его название, моим первым выбором действительно был параметр obey pam restrictions. Поэтому я установил его на no(, но мог бы просто закомментировать, потому что по умолчанию он равенno).

Перезапустил службу smbd, вышел из системы и снова вошел в систему, а также снова попытался воспроизвести состояние ошибки.

На этот раз воспроизвести его не удалось. Таким образом, очевидно, обстановка obey pam restrictionsповлияла на весь этот pam_unixи samba:sessionбизнес.

Изменить #1:в упомянутом билете была запрошена дополнительная информация. В частности, в pam-auth-updateменя попросили деактивировать все, кроме настройки аутентификации Unix . Вот так:

[*] Unix authentication
[ ] Register user sessions in the systemd control group hierarchy
[ ] Create home directory on login
[ ] eCryptfs Key/Mount Management
[ ] Inheritable Capabilities Management

И оказалось, что проблема была не во втором параметре, связанном с systemd -, а в четвертом:eCryptfs Key/Mount Management .

Извлеченные уроки

1. Не назначайте награду, если собираетесь расследовать это самостоятельно
2. культ карго мусор может действительно навредить тому, что вы делаете... именно эту настройку я как бы носил с собой в моем управлении конфигурацией для smb.conf, хотя, очевидно, к настоящему времени ее можно было бы выбросить... да ладно
3. Если ничего не помогает, грубая сила, пробы и ошибки кажутся жизнеспособными методами поиска основной причины