Как закрыть файловые сессии?

Question

[korolin2k]

Доброго времени суток!

В Windows Server 2019 перед резервным копированием через планировщик срабатывает PowerShell скрипт, который принудительно разрывает файловые сессии у пользователей:

Get-SMBOpenFile | where {$_.Path -like "*.*"} | Close-SMBOpenFile -Force

По факту файловые сессии не закрываются (Управление компьютером - Общие папки - Открытые файлы)
Запустил скрипт вне планировщика от имени админа, посыпались ошибки вида:

Close-SMBOpenFile : Нет открытого файла с данным идентификационным номером. 
C:\ps\useroff.ps1:1 знак:49
+ ... -SMBOpenFile | where {$_.Path -like "*.*"} | Close-SMBOpenFile -Force
+                                                  ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MSFT_SmbOpenFile (FileId = 527744999433):ROOT/Microsoft/...SFT_SMBOpenFile) [Close-SmbOpenFile], CimExc 
   eption
    + FullyQualifiedErrorId : Windows System Error 2314,Close-SmbOpenFile
 
Close-SMBOpenFile : Буфер возврата API слишком мал. 
C:\ps\useroff.ps1:1 знак:49
+ ... -SMBOpenFile | where {$_.Path -like "*.*"} | Close-SMBOpenFile -Force
+                                                  ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MSFT_SmbOpenFile (FileId = 521839493137):ROOT/Microsoft/...SFT_SMBOpenFile) [Close-SmbOpenFile], CimExc 
   eption
    + FullyQualifiedErrorId : Windows System Error 2123,Close-SmbOpenFile

Может скрипт неправильно написан?

Comments

[Alexey Dmitriev]

ПО для резервного копирования должно уметь VSS, закрывать сессии - плохая и бессмысленная идея - они могут открыться заново.

[korolin2k]

Alexey Dmitriev, ПО установлено и делает VSS. Вышенаписанный скрипт как подстраховка.

[Роман Безруков]

По факту файловые сессии не закрываются

так вы SMB-сессии и не закрываете. Судя по приведенному коду, вы закрываете только открытые файлы в SMB-сессии. Для SMB-сессий есть Get-SmbSession и Close-SmbSession.

Вышенаписанный скрипт как подстраховка

подстраховка от чего?
Как отметил Alexey Dmitriev - "ПО для резервного копирования должно уметь VSS", этого достаточно для подавляющего большинства файловых серверов

[mumische]

Роман Безруков, тоже не панацея. Собственно самый работающий вариант - это делать Remove-SmbShare и после окончания New-SmbShare.

[MaxKozlov]

korolin2k, Мало того, судя по видимому куску
| where {$_.Path -like "*.*"} |
файлы без расширения вы не закрываете.
А файл с кодом ошибки "Нет открытого файла с данным идентификационным номером" уже и без вас успел закрыться

И в чём тогда смысл ?

[MaxKozlov]

mumische,

Собственно самый работающий вариант - это делать Remove-SmbShare и после окончания New-SmbShare.

Неверно. Самый работающий вариант - VSS. И если ваше ПО умеет в него, всё остальное просто не нужно. Потому что на процесс бэкапа с использованием VSS не влияет вообще никак.

[Роман Безруков]

mumische, в данном случае (да и в большинстве аналогичных) вообще нет никакой нужды что-то делать с открытыми файлами, SMB-сессиями и сетевыми шарами.

[mumische]

MaxKozlov, Вы почему-то привязались только к резервному копированию и VSS, игнорируя тот факт что бывает необходимость реализации совершенно других сценариев.

[MaxKozlov]

mumische, Ну так автор свой вопрос как поставил ?

как закрыть сессии уже Роман Безруков сказал,
для беспрепятственного доступа к открытым файлам (в том числе для бэкапа) есть VSS.

Какие ещё сценарии вы имеете ввиду ?

[mumische]

MaxKozlov, если столкнётесь - вспомните про этот вопрос. Нет - ну и замечательно.

[MaxKozlov]

mumische, То есть прямо сейчас вы не можете выдумать ещё сценариев ? :)

[Роман Безруков]

mumische, знаете - был у меня один забавный опыт, если кратко: Storage Replica с дисками ReFS, поверх которой натянут DFS-N с несколькими папками. SR умеет переключать направление реплики (SR Failover). Вот под такое переключение я пилил скрипт, в котором после переключения направления реплики на старом сервере-источнике, в том числе, отстреливались SMB-сессии (сетевые шары при этом уже отключены). Но даже после отключения SMB-сессии могли появится снова из-за особенностей SMB-клиентов

[MaxKozlov]

Роман Безруков, И чем закончилось дело ?

[Роман Безруков]

MaxKozlov, скрипт-то я сделал, и он даже работал как надо и переключал направление SR, пересоздавал папки, менял пути в DFS-N, но ресурсы после переключения становились доступны только через 15 минут...
В итоге SR разобрали, скопировали данные на новый файловый сервер с NTFS и дальше подняли DFS-N с DFS-R

P.S. потом до меня дошло, что надо было в конце скрипта пинать AD-репликацию, чтобы не ждать 15 минут - но проверить уже было не на чем :)

[Роман Безруков]

MaxKozlov, а клиенты, которые пересоздавали SMB-сессии, были разные сервисы на линуксах, которые подключались к расшаренной папке...приходилось перемонтировать

[MaxKozlov]

Роман Безруков, Интересно и поучительно :)
Однако, насколько я помню, 15 минут - это дефолтное время для кеширования таргета DFS, может быть дело было именно в этом, а не в репликации.

[Роман Безруков]

MaxKozlov, а да, может быть - в эту сторону я не подумал ...

[Роман Безруков]

MaxKozlov, ну, кстати, вот про кэш DFS - Change the amount of time that clients cache referrals
по дефолту: 5 минут для Namespace и 30 минут для Folders

[MaxKozlov]

Роман Безруков, Ну значит память меня подводит :)
15 минут где-то в другом месте
потому что внутрисайтовая репликация чаще, чем 15 минут, а межсайтовая вроде бы реже. Если вы её не подкрутили, конечно