Контейнер Windows службы приложений Azure - загрузка файла в общий файловый ресурс с помощью ошибки подключения хранилища

ProgramBox

Контейнер Windows службы приложений Azure — загрузка файла в общий файловый ресурс с помощью ошибки подключения хранилища

Post author:admin
Запись опубликована:10 марта, 2023
Post category:Вопросы по программированию

#c# #azure #azure-web-app-service #windows-container

#c# #лазурный #azure-web-app-service #windows-контейнер #azure

Вопрос:

У меня есть простое приложение .NET 4.5 mvc, которое выполняет простую загрузку файлов в каталог.

Это приложение было помещено в контейнер Windows и развернуто в веб-приложении службы приложений Azure в виде контейнеров.

У него есть возможность подключить хранилище файлов Azure в качестве постоянного тома хранилища к контейнеру.

Итак, я сопоставил монтирование с указанием каталога загрузки. Идея заключается в том, что когда пользователь загружает файл, он попадает в хранилище файлов Azure через подключаемый том.

Монтирование выполнено успешно, однако при попытке загрузить сообщение об ошибке «Неверный параметр» из system.IO .

Если мы проверим хранилище файлов Azure из проводника хранилища, создается пустой файл. Не уверен, что происходит не так.

 2020-10-17 02:36:20,959 82924433ms INFO  FileHelper             UpLoadFile             - ToFilePath : C:inetpubwwwrootFileStorageUserProfileImagesbanner-img.jpg
2020-10-17 02:36:20,975 82924449ms ERROR FileHelper             UpLoadFile             - Error in saving file. The parameter is incorrect.

2020-10-17 02:36:20,975 82924449ms ERROR FileHelper             UpLoadFile             - System.IO.IOException: The parameter is incorrect.

   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at System.Web.HttpPostedFile.SaveAs(String filename)
   at ConnecTiQa.Mvc.Helpers.FileHelper.UpLoadFile(HttpPostedFileBase file, HttpServerUtilityBase server, String rename, String SaveFilePath) in C:appConnecTiQa.MvcHelpersFileHelper.cs:line 204

Скриншот учетной записи хранилища

Обновление 1:

Не только обновление. Также возникла проблема с доступом к файлу (чтением) с подключенного тома.

Ошибка доступа к файлу тома для монтирования

1. это именно та проблема, с которой я столкнулся, и ничего из того, что я пробовал, не сработало … просто используя командную консоль kudu и переходя в подключенный общий файловый ресурс и выполняя «тип filename.txt «показывает ту же проблему «Неверный параметр». Пожалуйста, напишите, если вы добились какого-либо прогресса.

2. Я связался с Microsoft, и они сказали: «Эта ошибка была подтверждена группой продуктов, и в настоящее время они работают над ее устранением как можно скорее. Однако в настоящее время нет ETA относительно того, когда ошибка будет исправлена «.. Я запросил ссылку на проблему / тикет, чтобы я мог отслеживать, когда она будет решена, но пока не получил ответа. Итак, хорошая новость в том, что, вероятно, мы не делали ничего плохого, мы были просто единственными 2 людьми в мире, которые пытались это сделать!

3. Сегодня также открыл запрос в службу поддержки по этой проблеме. Я перешлю эту информацию и сообщу, если получу какую-либо информацию. Я могу выполнить «dir», но не могу читать / записывать какие-либо файлы.

Ответ №1:

Это было слишком долго для публикации в качестве комментария. Напрямую из службы поддержки Майкрософт:

Контейнеры, изолированные от гипервизора, запускаются внутри облегченного компонента, называемого UVM (служебная виртуальная машина). Когда каталог с хоста отображается в контейнер Windows, изолированный от гипервизора, Hyper-V использует VSMB (virtual SMB) для отображения общего ресурса в UVM. VSMB поддерживает оптимизацию, называемую direct map, которая уменьшает нагрузку на память на хосте для общего ресурса. В рамках поддержки direct map VSMB должен иметь возможность запрашивать идентификатор файла, к которому осуществляется доступ. Таким образом, в этом случае VSMB будет запрашивать файлы Azure для получения идентификатора файла. Однако Azure Files в настоящее время не поддерживает запрос идентификатора файла из своих общих ресурсов, и именно это приводит к ошибке ERROR_INVALID_PARAMETER, которая наблюдается при доступе к общему ресурсу.

Здесь фактически две проблемы: Azure Files не поддерживает запрос идентификатора файла. Я запустил поток с контактом в Azure Files, чтобы узнать, могут ли они поддерживать это в будущем. При сбое запроса идентификатора файла VSMB не возвращается к использованию непрямого сопоставленного доступа к общему ресурсу. Эта ошибка существует в 19H1, 20H1 и 20H2. В RS5 VSMB не запрашивал идентификатор файла, но это было изменено в 19H1, чтобы сделать VSMB более корректным и устранить другие ошибки. После 20H2 эта ошибка была исправлена, так что VSMB вернется к непрямому отображению, если запрос идентификатора файла завершится неудачно, но с момента исправления ошибки не было новой версии Windows Server. Исправление будет доступно в следующем выпуске Windows Server.

Но все же у нас есть проблема с файлом Azure, который не поддерживает запрос идентификатора файла, и на данный момент нет ETA. Команда Windows рассматривает это в этом случае обходной путь, рекомендованный нашей группой продуктов, заключается в использовании другого механизма, такого как Azure SDK для .СЕТЬ для чтения / записи файлов в хранилище

1. Спасибо за обновление, я понимаю, что проблема должна быть устранена сейчас. Инженеры обнаружили, что проблема возникла из-за регрессии, введенной в выпуске Windows SAC 20H1, который используется службой приложений Azure для питания контейнеров Windows. В конце декабря 2020 года в службы приложений было внедрено частное исправление, которое будет удалено через несколько месяцев, когда в первом квартале 2021 года будет выпущено соответствующее исправление для Windows. У меня нет тестовой среды, чтобы подтвердить, что она работает.

Ответ №2:

~~Проблема в том, что монтирование в контейнере Windows имеет только разрешение RX, см. Скриншот здесь:~~
~~у вас нет разрешения на запись в точке монтирования, поэтому вы не можете записывать содержимое в файлы.~~

Обновить:

Я допустил ошибку и сожалею об этом. Точка подключения — это путь, который вы задаете в сопоставлениях путей. Например, если вы задаете путь монтирования как /inetpub/wwwroot/filestorage/mnt , то точка монтирования является конечной папкой mnt , и все действия в ней будут неправильными:

Я не уверен, что это проблема, но я предполагаю, что это проблема.

1. Спасибо за ваши комментарии. Но у меня также есть проблемы с read. Обновил мой вопрос с подробностями

2. /inetpub/wwwroot/filestorage/ это моя точка монтирования. если ввести dir, можно просмотреть список всех существующих файлов. но не удается прочитать или записать.

3. @Singaravelan Да, это верно. Вы можете видеть их все, но вы ничего не можете с ними сделать. В этом проблема. В контейнере Linux этой проблемы нет.

4. @CharlesXu не могли бы вы расширить немного больше, пожалуйста — у меня такая же проблема… Контейнер Windows, с Azure Files SMB file share мое приложение может просматривать общую папку и файлы в ней, но не может прочитать содержимое или записать содержимое. Вы предполагаете, что было выполнено неправильное подключение хранилища Azure, если да, можете ли вы привести пример того, как это должно быть сделано правильно? Сингара велан если у вас все получится, пожалуйста, отправьте сообщение (определенно проблема с разрешениями, но пытаюсь выяснить, почему).

5. @CharlesXu RobertShattock, мы перешли к одному из партнеров Microsoft, увидим любое обходное решение.