Ошибка ConditionHeadersNotSupported у веб-приложения, использующего службу файлов Azure из браузера
Ошибка ConditionHeadersNotSupported возникает при доступе к содержимому, размещенному в службе файлов Azure, через приложение, в котором используются условные заголовки, например в веб-браузере, и происходит сбой доступа. Эта ошибка свидетельствует о том, что условные заголовки не поддерживаются.
Причина
Условные заголовки пока не поддерживаются. Приложения, в которых реализована эта возможность, должны запрашивать полный файл при каждом обращении к файлу.
Возможное решение
При передаче нового файла свойству cache-control по умолчанию присваивается значение “no-cache”. Чтобы заставить приложение запрашивать файл каждый раз, нужно изменить у файла свойство cache-control со значения “no-cache” на значение “no-cache, no-store, must-revalidate”. Это можно сделать с помощью Обозревателя службы хранилища Azure.
Монтирование разделяемых файловых ресурсов
Для монтирования разделяемых файловых ресурсов на компьютере-клиенте должен быть установлен пакет cifs-utils:
sudo apt install cifs-utils |
Монтирование разделяемого файлового ресурса выполняется командой с указанием соответствующего типа сетевой ФС, например:
sudo mount.cifs //сервер/ресурс /точка_монтирования sudo mount -t cifs //сервер/ресурс /точка_монтирования |
В качестве опций команде могут передаваться параметры монтирования, такие как имя пользователя, используемый тип аутентификации, кодировка, использование прав доступа и т.п. При этом точка монтирования /media/share1 должна быть создана заранее и доступна пользователю, например:
sudo mkdir /media/share1sudo chmod 777 /media/share1sudo mount -t cifs //fileserver1.org.net/share1 /media/share1 -o user=пользователь |
Без соответствующей записи в /etc/fstab пользователь может использовать команды монтирования только с помощью .Для возможности монтирования разделяемого файлового ресурса пользователем в конфигурационном файле /etc/fstab должна быть объявлена строка монтирования, например следующего вида:
//fileserver1.org.net/share1 /media/share1 cifs user,rw,noauto,iocharset=utf-8,soft 0 0 |
Точка монтирования должна быть создана заранее и доступна пользователю для чтения/записи, опция user предоставляет возможность монтирования указанного ресурса простому пользователю.Пользователь при этом выполняет монтирование командой mount с указанием точки монтирования:
mount /media/share1 |
Полный список опций приведен в руководстве для команд и . Описание формата конфигурационного файла /etc/fstab приведено в руководстве для fstab.
Для того чтобы пользователю были доступны каталоги при входе с ненулевой классификационной меткой нужно в файле /etct/fstab на компьютере клиента указать следующие параметры:
//fileserver1.org.net/share1 /media/share1 cifs user,rw,noauto,iocharset=utf-8,nosharesock,vers=1.0,soft 0 0 |
При использовании с аутентификацией Kerberos в ЕПП в строке опций должен быть указан параметр аутентификации sec=krb5i или sec=krb5. В этом случае при монтировании будет использоваться текущий кэш Kerberos пользователя.
|
«Mount error(13): Permission denied» (Ошибка подключения(13). Отказ в разрешении) при подключении общей папки Azure
Причина 1: незашифрованный коммуникационный канал
Из соображений безопасности, если коммуникационный канал не зашифрован, а попытка подключения осуществляется не из того же центра обработки данных, в котором находятся файловые ресурсы Azure, то подключение к ним Azure будет заблокировано. Незашифрованные подключения в одном центре обработки данных также могут быть заблокированы, если в учетной записи хранения включен параметр Требуется безопасное перемещение. Шифрование коммуникационного канала выполняется, только если клиентская ОС пользователя поддерживает шифрование SMB.
Подробнее см. в статье .
Решение для причины 1
- Подключитесь из клиента, поддерживающего шифрование SMB, или из виртуальной машины, размещенной в том же центре обработки данных, что и учетная запись хранения Azure, используемая для файлового ресурса Azure.
- Убедитесь, что параметр Требуется безопасное перемещение отключен в учетной записи хранения, если клиент не поддерживает шифрование SMB.
Причина 2: правила виртуальной сети или брандмауэра включены для учетной записи хранения
Если для учетной записи хранения настроены правила виртуальной сети и брандмауэра, доступ сетевого трафика будет запрещен, если IP-адрес клиента или виртуальная сеть не разрешают доступ.
Решение для причины 2
Убедитесь, что правила виртуальной сети и брандмауэра настроены надлежащим образом для учетной записи хранения. Чтобы проверить, связана ли проблема с правилами виртуальной сети или брандмауэра, временно задайте для учетной записи хранения параметр Разрешить доступ из всех сетей. Подробнее см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей (предварительная версия).
Устранение неполадок доступа к общей папке Windows XP из Fedora:
Вы получаете сообщение об ошибке:
1. Убедитесь, что Linux может пинговать другой блок.
Запустите эту команду в поле linux для IP-окна окна:
Если вы не можете добраться до коробки или подключаться к ней, вы можете подать жалобу.
2. Убедитесь, что папка на самом деле разделена на окна, выполните следующие действия.
Откройте браузер файлов в .
Создайте новую папку с именем . Итак, теперь у вас есть C: \ public
Внутри этой папки создайте новый текстовый документ под названием «test.txt».
Щелкните правой кнопкой мыши папку и перейдите к свойствам.
Перейдите на вкладку совместного доступа.
Убедитесь, что: «Обмениваться этой папкой в сети» отмечен
Обратите внимание на общее имя: «public». Нажмите «ОК»
Маленькая рука должна появиться под папкой, то есть она разделена.
Папка ‘public’ теперь используется совместно, и вы должны иметь возможность подключиться к ней с помощью Linux.
3. В Linux установите общий ресурс с помощью «mount»:
- Откройте консоль и для root.
-
создать каталог Это будет доступ к общим файлам.
-
запустите команду mount, которая запрашивает пароль:
-
В приведенной выше инструкции предлагается ввести пароль, ввести правильный пароль, неверный приведет к ошибке. Если вы не уверены в пароле, вы можете изменить пароль в окне окна под панелью управления -> Учетные записи пользователей.
-
запустите команду и запустите . Представлено содержимое диска:
-
Вы подключились к приводу Windows.
4. Подключитесь к общему диску с помощью браузера konqueror или linux:
- Откройте браузер файлов, в моем случае konqueror.
- В строке местоположения файла введите и нажмите клавишу ввода.
- Вам может быть предоставлен логин и пароль. Введите имя пользователя и пароль окна окна, описанного в верхней части этого сообщения.
- Поздравляем, вы подключены к общей папке.
Автоматическое монтирование ресурсов CIFS
Вместе с тем описываемое подключение позволяет использовать ресурсы samba в доверенной локальной сети всем пользователям локальной машины с авторизацией от имени выделенного (непривилегированного) пользователя.
В качестве основы для создания скрипта /etc/auto.cifs использован скрипт auto.smb поставляемый с пакетом autofs5 с небольшими доработками.
Для использования этого способа в дополнение к собственно samba должен быть установлен пакет cifs-utils:
обавляем в /etc/auto.master строк
Создаем файл /etc/auto.cifs:
Комментарии к файлу
- < opts=»-fstype=cifs,file_mode=0644,dir_mode=0755,codepage=866,iocharset=utf-8,user=$user_password» > : строка для обеспечения просмотра русских букв на ресурсах windows
- < $SMBCLIENT —user=$user_password -gL $key 2>/dev/null| awk -v key=»$key» -v opts=»$opts» -F’|’ — ‘ > : строка <$SMBCLIENT …> изменена для обеспечения возможности подключения к samba-ресурсам windows
- < user_password=$(cat $credfile | grep «$key» | awk -F «:» ‘{print $2}’) > : строка добавлена для получения из файла пароля доступа к ресурсу cifs
Для монтирования ресурсов Windows следует использовать более простую строчку опций монтирования, например для Windows Server 2012:
Для более старых версий Windows Server может понадобиться ограничить версию используемого протокола:
Делаем скрипт auto.cifs ис:
sudo chmod 755 /etc/auto.cifs
Создаем файл с паролями доступа к ресурсу cifs /etc/user-cifs со строчками
целях безопасности устанавливаем права к файлу /etc/user-cifs только для root:
600 /etc/user-cifs
sudo systemctl restart autofs
Обращаемся в командной строке к ресурсу samba:
ls /media/cifs/ХОСТ1
Монтирование CIFS ресурсов c авторизацией через Kerberos
Если монтирование выполняется на компьютере с настроенной авторизацией через Kerberos, то монтровать ресурсы можно с помощью принципала Kerberos.
Для этого:
Убедиться, что служба CIFS правильно настроена на работу с Kerberos, для чего убедиться, что в файле /etc/request-key.d/cifs.spnego.conf пристутвует опция -t, а если её нет — то добавить её.В итоге содержимое файла должно быть следующее:
Получить/обновить принципала Kerberos (если монтирование делается от имени суперпользователя, то и принципал должен быть получен от того же пользователя):
kinit username
Убедиться, что принципал получен:
klist
И команда монтирования (для примера монтируем ресурс //server.windomain.ru/share в каталог /mnt):
mount -t cifs //server.windomain.ru/share /mnt -o sec=krb5
Автоматическое монтирование ресурсов при входе пользователя с помощью pam_mount
Для автоматического монтирования разделяемых файловых ресурсов при входе пользователя используется pam модуль pam_mount, предоставляемый пакетом libpam-mount, то есть для автоматического монтирования разделяемых файловых ресурсов на компьютере-клиенте должны быть установлены пакет cifs-utils и libpam_mount:
sudo apt install cifs-utils
Настройка модуля pam_mount осуществляется с помощью конфигурационного файла /etc/security/pam_mount.conf.xml.
При установке пакета libpam_mount вызов модуля pam_mount автоматически вносится в соответствующие pam-сценарии (common-auth, common-session) в каталоге /etc/pam.d.
Описание возможностей модуля pam_mount и формат его конфигурационного файла приведены в руководстве для pam_mount и pam_mount.conf.
/etc/security/pam_mount.conf.xml
<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd"> <!-- See pam_mount.conf(5) for a description. --> <pam_mount> <!-- debug should come before everything else, since this file is still processed in a single pass from top-to-bottom --> <debug enable="1" /> <!-- Volume definitions --> <cifsmount>mount.cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o %(OPTIONS) </cifsmount> <!-- pam_mount parameters: General tunables --> <!-- Описание тома, который должен монтироваться --> <volume fstype="cifs" server="ipa0.ipadomain.ru" path="share1" mountpoint="/media/%(USER)" options="user=%(USER),cruid=%(USER),sec=krb5i" /> <!-- <luserconf name=".pam_mount.conf.xml" /> --> <!-- Note that commenting out mntoptions will give you the defaults. You will need to explicitly initialize it with the empty string to reset the defaults to nothing. --> <mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" /> <!-- <mntoptions deny="suid,dev" /> <mntoptions allow="*" /> <mntoptions deny="*" /> --> <mntoptions require="nosuid,nodev" /> <logout wait="50000" hup="1" term="1" kill="1" /> <!-- <logout wait="0" hup="no" term="no" kill="no" /> --> <!-- pam_mount parameters: Volume-related --> <mkmountpoint enable="1" remove="true" /> </pam_mount>
Вариант описания тома для монтирования домашних каталогов пользователей (предполагается, что на сервере samba настроен специальный ресурс home):
... <volume fstype="cifs" server="ipa0.ipadomain.ru" path="%(USER)" mountpoint="/home/%(USER)" options="user=%(USER),cruid=%(USER),sec=krb5i" /> ...
При использовании с аутентификацией Kerberos в ЕПП в строке опций монтирования должен быть указан параметр аутентификации sec=krb5i (предпочтительно с точки зрения безопасности, но требует больше ресурсов) или sec=krb5. В этом случае при монтировании будет использоваться текущий кэш Kerberos пользователя.
Для точки монтирования mountpoint должен быть указан отдельный каталог, например: /media/ald_share. Пример:
Отображается сообщение «[permission denied] Disk quota exceeded» ([Отказано в разрешении]. Превышена дисковая квота) при попытке открыть файл
Работая в Linux, вы получаете сообщение об ошибке, которое имеет следующий вид.
<filename> Disk quota exceeded
Причина
Достигнуто максимально допустимое число открытых дескрипторов, разрешенных для файла или каталога.
Установлена квота в 2000 открытых дескрипторов на один файл или каталог. По достижении этого ограничения вы увидите соответствующую ошибку.
Решение
Сократите количество одновременно открытых дескрипторов, закрыв некоторые из них, и повторите операцию.
Чтобы просмотреть открытые дескрипторы для общей папки, каталога или файла, используйте командлет PowerShell Get-AzStorageFileHandle.
Чтобы закрыть открытые дескрипторы для общей папки, каталога или файла, используйте командлет PowerShell Close-AzStorageFileHandle.
Примечание
Командлеты Get-AzStorageFileHandle и Close-AzStorageFileHandle включены в модуль Az PowerShell версии 2.4 или выше. Информация о том, как установить модуль Az PowerShell последней версии, приведена в статье Установка модуля Azure PowerShell.
Медленное копирование файлов в службе файлов Azure и из нее в Linux
- Если определенные требования к минимальному размеру операций ввода-вывода отсутствуют, для оптимальной производительности мы рекомендуем использовать 1 МиБ.
- Используйте правильный метод копирования:
- Используйте AZCopy для передачи данных между двумя файловыми ресурсами.
- Параллельное использование cp или dd может повысить скорость копирования, количество потоков зависит от варианта использования и рабочей нагрузки. В следующих примерах используется шесть:
- Пример cp (в качестве размера блока cp будет использовать размер блока по умолчанию файловой системы): .
- Пример dd (эта команда явно устанавливает размер блока, равный 1 МиБ): .
- Средства сторонних разработчиков с открытым кодом, например:
- GNU Parallel.
- Fpart — сортирует файлы и упаковывает их в разделы.
- Fpsync — использует Fpart и средство копирования для создания нескольких экземпляров и переноса данных из src_dir в dst_url.
- Multi — многопоточное копирование и md5sum, основанные на GNU coreutils.
- Если задать размер файла заранее, чтобы каждый раз не использовать расширенную запись, это поможет повысить скорость копирования в сценариях с известным размером файла. Если нужно избежать использования расширенной записи, можно задать размер целевого файла с помощью команды . После этого команда скопирует исходный файл без необходимости постоянного обновления размера целевого файла. Например, можно задать размер целевого файла для каждого копируемого файла (предположим, что общая папка подключена к /mnt/share):
- а затем параллельно скопировать файлы без расширенной записи:
Низкая производительность файлового ресурса Azure, подключенного к виртуальной машине Linux
Причина 1: кэширование
Одной из возможных причин снижения производительности может быть отключенное кэширование. Кэширование может быть полезно при многократном обращении к файлу, в противном случае оно может стать дополнительной нагрузкой. Перед отключением кэширования проверьте, используется ли оно.
Решение для причины 1
Чтобы проверить, отключено ли кэширование, найдите запись cache=.
Запись cache=none означает, что кэширование отключено. Повторно подключите общедоступный ресурс, введя команду mount по умолчанию или явно добавив в нее параметр cache=strict, чтобы включить режим кэширования по умолчанию или «строгий» режим кэширования соответственно.
В некоторых сценариях параметр подключения serverino может привести к тому, что команда ls формирует статистику для каждой записи каталога. Это приводит к снижению производительности при выводе содержимого большого каталога. Параметры подключения можно просмотреть в записи /etc/fstab.
Можно также проверить, правильные ли параметры используются, выполнив команду sudo mount | grep cifs и проверив ее выходные данные. Пример выходных данных этой команды приведен ниже.
Если параметр cache=strict или serverino отсутствует, отключите и повторно подключите службу файлов Azure, выполнив команду mount из этой статьи. Затем еще раз проверьте наличие правильных параметров в записи /etc/fstab.
Причина 2: регулирование полосы пропускания
Возможно, у вас выполняется регулирование полосы пропускания и запросы отправляются в очередь. Это можно проверить с помощью метрик службы хранилища Azure в Azure Monitor.
Wabbit Intros и расширенные кредиты
В основном я создал учетную запись хранилища файлов в Azure с настройками, позволяющими подключать это хранилище в любой сети.
Когда я перехожу на свою виртуальную машину (также в Azure), я запускаю следующую команду (отредактировано)
Я получаю ошибку . Я уже открыл порты 445 и 139 в сетевых настройках виртуальной машины, но все равно не повезло.
Ошибки журналов следующие:
Если вы хотите подключить общую папку в учетной записи хранения Azure к виртуальной машине Azure Linux, вы можете следовать этому документу: Используйте файлы Azure с Linux. В вашем случае проблема, вероятно, заключается в вашем пароле, который должен быть ключом учетной записи хранения. Вы можете найти его в учетной записи хранения — настройки — Ключи доступа — выберите Key1 или Key2. Кроме того, по умолчанию исходящий трафик виртуальной машины Azure не имеет ограничений на порт 445. Вы должны убедиться, что исходящий трафик от виртуальной машины Azure к вашей учетной записи хранения не блокирует порт 445.
Подробные шаги:
- Для подключения в других регионах Azure, отличных от вашей учетной записи хранения, необходимо использовать SMB 3.0, поддержка шифрования SMB 3.0 была введена в ядре Linux версии 4.11.
- Пакет cifs-utils установлен. Например, вы можете запустить это в Ubuntu.
- Определите права доступа к каталогу / файлу подключенного общего ресурса. В приведенных ниже примерах разрешение 0777 используется для предоставления всем пользователям прав на чтение, запись и выполнение.
- Убедитесь, что порт 445 открыт: SMB обменивается данными через TCP-порт 445 — проверьте, не блокирует ли ваш брандмауэр TCP-порты 445 от клиента.
Не забудьте заменить имя-учетной-записи хранения, общее имя, smb-версия, ключ учетной записи хранения, а также Точка монтирования с соответствующей информацией для вашей среды. С моей стороны это работает, я использую Linux Ubuntu 4.15.0-1036.
- В моей виртуальной машине порт 445 открыт для любого протокола, с любого порта. С помощью той же команды, представленной в разделе «Подключение к Azure», я могу подключить это файловое хранилище к другой виртуальной машине, но не к этой.
- Обе ВМ находятся в одной подсети, регионе или ОС? Есть ли внутри виртуальной машины брандмауэр? Обе ВМ поддерживают SMB 3.0?
- Да, и виртуальная машина, и учетная запись хранилища находятся в одном регионе и подсети, я даже добавил общедоступный IP-адрес от виртуальной машины, но не повезло. Да, обе виртуальные машины поддерживают SMB 3, я пытался смонтировать SMB 2.1, но все равно получаю ту же ошибку.
- Ты можешь бежать для проверки сетевого подключения на проблемной виртуальной машине? Возможно, системный брандмауэр внутри виртуальной машины блокирует исходящий 445-й. Не могли бы вы проверить это на своей стороне, например или на Ubuntu? Больше ссылок.
- 1 Я тоже, если проблема была решена или вам нужна помощь, дайте мне знать.
Не удается создать символьные ссылки — ln: failed to create symbolic link ‘t’: Operation not supported (ln: не удалось создать символьную ссылку «t». Операция не поддерживается)
Причина
По умолчанию при подключении общих папок Azure в ОС Linux с помощью CIFS поддержка символьных ссылок (symlink) не включается. Ошибка будет выглядеть примерно так:
Решение
Клиент CIFS в ОС Linux не поддерживает создание символьных ссылок в стиле Windows по протоколу SMB 2 или SMB 3. Сейчас клиент Linux поддерживает для операций создания и отслеживания символьные ссылки в другом стиле (). Если клиенту требуются символьные ссылки, он может использовать параметр подключения mfsymlinks. Мы рекомендуем использовать mfsymlinks, так как этот формат используется компьютерами Mac.
Чтобы использовать символьные ссылки, добавьте следующий текст в конец команды подключения CIFS:
Команда будет выглядеть примерно так:
Теперь вы сможете создавать символьные ссылки, как описано на .
Отображается сообщение «Mount error(112): Host is down» (Ошибка подключения (112). Узел не работает) из-за истечения времени ожидания повторного подключения
Ошибка подключения (112) возникает в клиенте Linux, если он бездействует в течение длительного времени. Когда клиент долгое время бездействует, он отключается, и время ожидания его подключения истекает.
Причина
Подключение может бездействовать по следующим причинам:
- сбои сети, которые мешают повторно установить подключение TCP к серверу, если используется режим «мягкого» подключения (режим по умолчанию);
- последние исправления повторного подключения, отсутствующие в ядрах предыдущих версий.
Решение
Эта проблема повторного подключения в ядре Linux исправлена в рамках следующих изменений:
- Исправление повторного подключения к неотложенному сеансу переподключения mb3 через продолжительное время после повторного подключения сокета
- Вызов службы echo сразу же после повторного подключения сокета
- CIFS: устранение возможного повреждения содержимого памяти во время повторного подключения
- CIFS: устранение возможной двойной блокировки мьютекса во время повторного подключения — для ядра v4.9 и более поздних версий
Тем не менее эти изменения могут быть перенесены еще не во все дистрибутивы Linux. Если вы используете популярный дистрибутив Linux, вы можете обратиться к разделу Использование Файлов Azure в Linux, чтобы узнать, в какой версии дистрибутива есть необходимые изменения ядра.
Возможное решение
Можно обойти эту проблему, указав жесткое подключение. Жесткое подключение вынудит клиент ожидать установки подключения или явного прерывания. Вы можете использовать этот вариант, чтобы избежать ошибок из-за истечения времени ожидания сети. Тем не менее этот способ может породить неопределенное время ожидания. Будьте готовы останавливать подключения при необходимости.
Если не удается выполнить обновление до последних версий ядра, можно решить эту проблему, поместив в файловый ресурс Azure файл и перезаписывая его каждые 30 секунд (или чаще). Это должна быть операция записи, такая как перезапись даты создания или изменения файла. В противном случае можно получить кэшированные результаты, в итоге операция записи не активирует повторное подключение.
3 ответа
13
способен искать имена хостов
Невозможно найти имена хостов
Чтобы подключиться по имени, вы должны использовать локальную службу DNS, такую как Avahi. Без локального DNS вы должны указать IP-адрес при подключении. Вы можете использовать , чтобы узнать IP-адрес.
Обычно лучшим способом доступа к общим ресурсам является использование . Это позволит вам установить много общих ресурсов без разрешения root.
Маска для smbnetfs расскажет вам больше.
Если для общего ресурса требуется логин и пароль, выполните следующие действия.
Отредактируйте файл , чтобы вставить учетные данные. Формат файла
Была ли та же проблема, которая пыталась установить NAS. Оказывается, нужны разные команды для (я думаю, это было) разных форматов, например, ext 4, NTFS и т. Д. Когда я в конце концов нашел правильную версию, я смог смонтировать через и терминал.
Мы используем Iomega NAS
Этот работает
Сначала я использовал формат номера вместо имени, но числа менялись. Неудачно, чтобы дать постоянные IP-адреса, где это необходимо, дало машине имя и теперь оно работает.
Однако это перестало работать над версиями nadia и майя (2 разных ПК). Надя начала работать, возможно, из-за обновления? (не знаю, что делать, чтобы исправить это, несмотря на попытки). Майя все еще не работает. Насколько я знаю, я ничего не менял. Так что, похоже, там могут быть какие-то проблемы.
У меня были такие же симптомы, и мне пришлось подтолкнуть Avahi, чтобы начать новую установку 18.04.1 (которая уже была перезагружена много раз). Потом все сработало. Я подозреваю, что многие люди в конечном итоге задают эти вопросы, возможно, не понимают, что они не запускались на их VM по какой-либо причине и т. Д.
Пожалуйста, см. , прежде чем читать больше моих, что было одним из самых полезных сообщений для этот вопрос, и вопрос был большим кратким вопросом.
Благодаря новым установкам от 18.04.1 на VMware он работал из коробки. В VirtualBox мне пришлось настроить сеть на VirtualBox на «Bridged Adapter», а затем включить Avahi и добавить к имени хоста. Я установил VMware много раз и никогда не испытывал проблем, пока не попробовал VirtualBox несколько дней назад.
В моем двухдневном приключении я обнаружил, что Avahi не запускался правильно на свежих 18.04.1 в настройках VirtualBox, где, казалось, все начиналось нормально на новых установках VMware. Кроме того, в VMware происходит еще одна магия, так как мне не нужно добавлять , для имени машины XXX и установки VMware I может просто использовать простое имя хоста Windows.
В VirtualBox, если бы я сделал:
до этого, с добавленным :
, тогда он работает.
Некоторые люди утверждают, что изменение должно исправить разрешение имени. Но после настройки и добавления в список по-разному, это не сработало и добавление или удаление кажется, фактически не влияет на . Возможно, файл не использовался.
См. также https://ubuntuforums.org/showthread.php?t=2099537, который является очень кратким примером того, кто имеет проблему, и кто-то показывает синтаксис для исправления его команды, если вы просто не заметили различий при использовании разрешения Avahi.
УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ, если вышеуказанное не работает.
Шаг 1: Вы пытались перезапустить оба компьютера.
Перезагрузите оба компьютера. После этого убедитесь, что все ваши обновления Windows сделаны. Убедитесь, что Linux также имеет свои обновления программного обеспечения. Перезагрузитесь после обновлений.
Шаг 2. Просмотрите свои брандмауэры, ZoneAlarms и другое программное обеспечение безопасности
Часть программного обеспечения, предназначенного для защиты вашего компьютера от вирусов, вредоносного ПО или зла в Интернете, может блокировать попытку совместного использования файлов. Брандмауэр Windows может находиться в параноидальном режиме. Хотя маловероятно, что Windows Firewall виноват, временно отключите его, чтобы убедиться, что это не проблема. (не оставляйте его).
Получите список всех программ безопасности, которые могут быть настроены на режим параноидальности. Брандмауэры Windows, сторонние брандмауэры, ZoneAlarms, антивирусы, Kaspersky, AVG или что-то еще, что утверждает, что защищает вас от вирусов /вредоносных программ /зла. Вам нужно будет просмотреть их и либо временно отключить их, либо открыть для них белый список для вашего IP-адреса.
Шаг 3: Получите подсказки от программного обеспечения безопасности.
ZoneAlarm хранит журнал всех событий и попыток совместного доступа к папке, переходите к предупреждениям и журналам Overview->. И посмотрите список всех неудачных попыток. То же самое можно сделать и для другого программного обеспечения. В этом случае он защитит вас от вас.
Шаг 4: Подозрительные проблемы в маршрутизаторе или локальной сетиСам
Возможно, маршрутизатор, беспроводные мосты, немые хабы или другое сетевое устройство имеют в себе некоторый директивный махинац, блокируя попытку подключения к общей папке. Маршрутизатор или устройство могут блокировать порт или иметь что-то в ограничительном режиме. Кто-нибудь обманывал его в последнее время? Попробуйте снова установить маршрутизатор на значение по умолчанию и повторите попытку.
Шаг 5. Убедитесь, что ваша локальная сеть проста и правильная.
Оба компьютера подключаются к одному маршрутизатору? Возможно, один связан с чистым беспроводным мостом netgear, а другой с маршрутизатором? Упростите сеть, подключив все компьютеры к одному маршрутизатору. Перезагрузите маршрутизаторы и Интернет, повторите попытку.
Шаг 6: Не работает. Изолируйте неисправный блок.
Пришло время стадным кошкам и изолировать неисправный блок. Докажите, что окно Windows не делит ваш файл, подключившись к общему ресурсу с помощью другого компьютера. Получите друзей Windows-ноутбук или продукт Apple и подключите его к своей сети и посмотрите, смогут ли они получить доступ к этой акции. Если они не могут, окно окна имеет проблему, если это возможно, проблема с Linux.
Шаг 7. Подозреваем, что брандмауэр в Linux
Обратите внимание на любой специальный аварийный сигнал безопасности или специальное программное обеспечение брандмауэра в Linux. Запустите и убедитесь, что smb установлен
Убедитесь, что Linux не препятствует вашему монтированию. Создайте общий ресурс smb в другом ящике Linux и попробуйте подключиться к нему.
Добавление более возможных решений этой проблемы
Это сообщение об ошибке не очень очертательно, но это значит, что операция была отключена. Для этого существует множество возможных причин, и, исследуя эту проблему, я столкнулся с некоторыми решениями, которые еще не упоминались в этом потоке.
1.) Неоднозначная сеть
Это не часто упоминается в различных решениях, которые вы можете найти в этой проблеме в Интернете, но сервер, к которому вы подключаетесь, должен находиться в той же подсети, что и ваша локальная машина. Эта проблема возникла для меня, потому что у меня были подключены как проводные, так и беспроводные соединения, и определение, какая подсеть принадлежит устройству, была двусмысленной, поскольку два соединения не являются одной и той же сетью. Отключение Wifi немедленно устранило проблему. Я наткнулся на это решение, читая Das Werkstatt :
2.) Новые строки в конце файла учетных данных
Файлы учетных данных полезны, если в вашем пароле есть специальные символы, такие как запятая . Его можно найти в следующих параметрах:
Файл отформатирован с помощью -образной переменной:
Если вы используете файл учетных данных, убедитесь, что в конце нет символов новой строки, или он будет тайм-аут при попытке проанализировать файл учетных данных:
3.) Попытка монтировать определенный каталог, а не фактическую точку общего доступа
Если конкретный каталог, который вам нужен, является подкаталогом общего ресурса, вы не сможете напрямую установить эту папку. Попытка сделать это приводит к нескольким различным ошибкам, это один из них.
Вместо этого смонтировать точку общего доступа, а затем добавить символическую ссылку в необходимый вам подкаталог:
Таким образом, вы получаете тот же результат, что и сам монтаж самого подкаталога, без необходимости его разворачивать каждый раз.