Как предотвратить блокировку файла в samba после отключения клиента?

Здесь у меня есть сервер Samba (Debian 5.0), который настроен для размещения профилей Windows XP.

Клиенты подключаются к этому серверу и работают со своими профилями непосредственно на общем ресурсе samba (профиль не копируется локально).

Время от времени клиент может не завершить работу должным образом, и поэтому Windows не освобождает файловые блокировки. Глядя на таблицу блокировок samba, мы видим, что многие файлы по-прежнему заблокированы, даже если клиент больше не подключен. В нашем случае это происходит с файлами блокировки, созданными Mozilla Thunderbird и Firefox. Вот пример таблицы блокировки самбы:

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

Мы видим, что файлы были открыты Windows и наложили блокировку DENY_ALL.

Теперь, когда клиент повторно подключается к этой общей папке и пытается открыть эти файлы, samba сообщает, что они заблокированы, и запрещает доступ.

Есть ли способ обойти эту ситуацию или я что-то упустил?

Изменить: Мы хотели бы избежать блокировки файлов на сервере Samba, потому что есть веские причины, чтобы включить их.

Следующие шаги помогли мне решить эту проблему несколько раз:

1. Авторизуйтесь на сервере samba.
2. Запустите "smbstatus".
3. Найдите pid процесса, который заблокировал файл, в третьем разделе вывода.
4. Убедитесь, что оно соответствует ожидаемому пользователю и имени хоста в первом и втором разделах вывода smbstatus.
5. Запустите "ps -ef" и посмотрите, как долго работает smbd с этим pid.
6. Если он работал с момента последней перезагрузки компьютера, это означает, что smbd остался. Убей ТОЛЬКО ТОГО, ЧТО-ТО (И убедитесь, что вы получите правильный - это должен быть тот, у которого родительский pid не равен 1.)

Посмотри на:

reset on zero vc = yes / no

и посмотрим, исправит ли это вашу проблему или нет.

Со smb.confстраницы руководства :

Этот логический параметр определяет, должны ли настройки входящего сеанса уничтожать другие соединения, приходящие с того же IP-адреса. Это соответствует поведению Windows 2003 по умолчанию. Установка для этого параметра значения yes становится необходимой, если у вас нестабильная сеть, и Windows решает восстановить соединение, в то время как старое соединение все еще имеет файлы с открытыми режимами общего доступа. Эти файлы становятся недоступными по новому соединению. Клиент отправляет нулевой VC на новое соединение, а Windows 2003 убивает все другие соединения, исходящие с того же IP. Таким образом, заблокированные файлы снова доступны. Помните, что включение этой опции приведет к разрыву соединений за маскирующим маршрутизатором.

Редактировать :
я просто подумал над другим возможным решением. Вы можете сделать что-то вроде этого на долю, о которой идет речь.

veto oplock files = /*.lock/

Это только предотвратит оплокирование файлов .lock.

Некоторые очень умные люди в Samba решили убрать эту опцию, и замены ей нет.

Тогда что касается совместимости с SMB, так как это действительно поведение по умолчанию.

Если пользователь не разбирается в командной строке Linux и в том, как убивать открытые файлы / процессы, вам придется перезапустить SMBD или сам сервер, чтобы очистить это.

Замечательно сделано, Samba.org.

Я столкнулся с подобной проблемой, клиент потерпел крах при копировании большого файла, и файл был заблокирован после перезагрузки. К счастью, это случается не очень часто, но все же раздражает необходимость убивать процесс самбы. reset on zero vcКазалось бы, это просто решение, но оно предположительно удалено из Samba4, хотя версия 4.7.6 в Fedora (27) все еще имеет его (возможно, исправлена ​​RH). В любом случае, это не очень поможет, поскольку на странице руководства написано, что он работает только с SMB1 (который больше не должен использоваться) и ничего не делает с соединениями SMB2 и SMB3, единственный оставшийся способ справиться с этим упоминается в нить, связанная Micheal . Я не знаю обоснование удаления и что плохогоreset on zero vcЯ хотел бы рассмотреть использование тайм-аута tcp для этой цели больше как взломать. В любом случае что-то разумное может быть, например,

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

Это прервет соединение примерно через 40 секунд (30 + 3 * 3) после последнего сеанса связи, что обычно более чем достаточно для обнаружения сбоя и перезагрузки (учитывая, что стек tcp сервера достаточно умен, чтобы закрыть соединение, когда клиент отклоняет пакеты keepalive после перезагрузки).

Обратите внимание, что это увеличивает нагрузку на вашу сеть, но я сомневаюсь, что это заметно даже при большом количестве клиентов.

Вы можете отключить оплоки для каждого ресурса с помощью следующего:

[acctdata]
oplocks = False
level2 oplocks = False

Тип блокировки по умолчанию - Уровень1. Оплокировки уровня 2 включены для каждого ресурса в файле smb.conf. Кроме того, вы можете отключить оплокировку для каждого файла в рамках общего ресурса:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

Если у вас возникли проблемы с операционными блокировками, как видно из записей журнала Samba, вы можете захотеть воспроизвести их безопасно и отключить блокировку и блокировку уровня 2.

Отключение оплонов ядра Опллоки ядра - это параметр smb.conf, который уведомляет Samba (если ядро ​​UNIX имеет возможность отправить клиенту Windows прерывание оплока), когда процесс UNIX пытается открыть файл, который кэшируется. Этот параметр предназначен для общего доступа к файлам между UNIX и Windows с включенными операционными блокировками на сервере Samba: процесс UNIX может открыть файл, который был заблокирован (кэширован) клиентом Windows, а процесс smbd не будет отправлять прерывание на операционную блокировку, которое подвергает файл риск повреждения данных. Если ядро ​​UNIX имеет возможность отправлять разрыв оплок, то параметр ядра oplocks позволяет Samba отправлять разрыв оплок. Оплокировки ядра включены для каждого сервера в файле smb.conf.

kernel oplocks = yes

По умолчанию нет.

Источник