Это надо вам, если у вашего Дримбокса нет жёского диска, а вы рано или поздно захотите записать какой-нибудь фильм, или наоборот — просмотреть или прослушать аудио-видео файлы с компьютера, или для решения других задач.

Что для этого надо?

В первую очередь желание и внимательность. Компьютер с сетевой картой, кроссоверный сетевой кабель и Dreambox.

Также, потребуется место, и притом много места, на жестком диске вашего компьютера.

Как это работает?

На компьютере под управлением Windows XP создается общедоступная (расшареная) папка, ей назначаются разрешения для определенного пользователя на чтение и запись.

А в Dreambox от имени этого самого пользователя монтирует (подключает) эту папку к себе в систему по сети, получая тем самым доступ к жёсткому диску вашего компьютере.

Настройка сети в данной статье не рассматривается. Но посмотри здесь:

Роутер или маршрутизатор TP-Link TL-WR340G / TL-WR340GD.

Установка роутера d-link di-604.

Проблема с маршрутизатором или роутером

Предполагается, что вы уже настроили сетевое подключение между компьютером и Дримом. А то… МАГЁМ.

Некоторые предостережения.

Работая в командной строке все команды, символы и знаки препинания пишем только в английской раскладке!!!

Пути к папкам и файлам в той раскладке, на языке какой они названы. Потому-как, например, русская «а » и английская «a » это совершенно разные буквы для компьютера.

Также, особое внимание обращайте на пробелы.

Пробел воспринимается компьютером точно также, как и другие буквы. Если в пути к папкам и файлам встречаются пробелы, то заключайте такие пути в двойные кавычки, например, как в такой команде:

net share dreamshare=»C:\Documents and Settings\Коля\Мои Документы\Мои Записи» /unlimited .

Сразу договоримся, что:

IP-компьютера = 192.168.0.1
IP-Дримбокса = 192.168.0.2
Расшариваемая папка = C:\dream_share
Её псевдоним = dreamshare
Пользователь = abc
Его пароль = def

Понятно что у вас может «ip» отличатся, но очень немного… обычно последняя циферка.

Будем работать только с командной строкой. Дальше вводим команды и жмём клавишу Enter !!!

Поехали:

В Windows: Пуск -> Выполнить -> cmd.exe

Добавим юзера «abc » с паролем «def «:
net user abc def /add /active:yes /passwordchg:no

(Кстати, если у вас имя пользователя записано аглицкими буквами, например Kolya, и есть пароль (также английскими или цифрами), то пользователя можно и не добавлять.

Для записи расшариваемую папку желательно создавать на скоростном винте с NTFS файловой системой и в несистемном разделе. Т.е. если у вас Windows находится в разделе C: , то папку желательно создавать в разделе D: или E: (если таковые имеются), и места в разделе должно быть побольше (20 GB и более).

А это важно…

Создадим папку для шары:
mkdir C:\dream_share

(Кстати, если у вас уже есть папка с видео и музыкой, можно использовать ее. Желательно, чтобы в пути к ней не было неанглийских букв и пробелов (иначе, читайте выше как это обойти).

Создадим подпапку, обязательную для видеозаписи:
mkdir C:\dream_share\movie

Создадим тестовый файл для проверки (на всякий случай):
echo test only — %date% > C:\dream_share\test.txt
Отключим простой доступ к общим файлам и папкам (строка длинная, но надо):
reg add «HKLM\SYSTEM\ControlSet001\Control\Lsa» /v «forceguest» /t REG_DWORD /d 0 /f

Расшарим папку и присвоим ей псевдоним dreamshare , через который Дрим будет обращаться к папке по сети:
net share dreamshare=C:\dream_share /unlimited

Разрешим юзеру «abc » подключать папку по сети и иметь к ней полный доступ (запись, чтение и т.д.):
cacls C:\dream_share /e /g abc:f

(Если команда cacls начала ругаться, то ваша расшариваемая папка находится в FAT32-разделе, и прийдётся немножко посчёлкать мышкой:

1. Пуск -> Панель Управления -> Свойства папок -> закладка Вид . Снимем галку с пункта «Использовать простой доступ к общим файлам «. Сохраняемся.
2. Правый клик мыши на расшариваемой папке -> Свойства -> закладка Общий доступ -> кнопка Разрешения . Добавим юзера «abc » и дадим ему полный доступ. Сохраняемся.

Ну, чтож, нам осталась самая малость: подмонтировать нашу папку к Дриму и проверить всё ли работает.

Возможно, на этом этапе потребуется перезагрузить компьютер и войти опять под своей учётной записью. Хотя у меня и так проходит — без перезагрузки.

Если перезагрузились, то возращаемся в cmd.exe .

Подключимся к Дриму по Telnet, для этого наберём:
telnet 192.168.0.2

Не забыли, что 192.168.0.2 это IP-адрес вашего Дримбокса, как мы и договаривались в начале.

Вводим логин:

Вводим пароль (по умолчанию dreambox ):

dreambox

Монтируем расшареную папку dreamshare с компьютера в папку /var/mnt/hdd на Дримбоксе от имени

пользователя abc (или как там вас кличут) и с паролем def (конечно своим) , возможно это займёт некоторое время:

Mount -t cifs -o rw,soft,udp,nolock,rsize=8192,wsize=8192,iocharset=utf8,user=abc,password= def //192.168.0.1/dreamshare /var/mnt/hdd

Проверяем:
mount -t cifs

И получим приблизительно вот такой вывод, который говорит, папка что dreamshare смонтирована:
//192.168.0.1/dreamshare on /var/mnt/hdd type cifs (rw,nodiratime,unc=\192.168.0.1\dreamshare,usernam e=abc,rsize=8192,wsize=8192)

Посмотрим, что есть в расшареной папке:
ls -l /var/mnt/hdd

И получим содержимое /var/mnt/hdd , где есть наши созданные файл test.txt и папка movie :
drwxrwxrwx 1 root root 7 Jul 29 2008 movie
-rwsrwsrwt 1 root root 7 Jul 29 2008 test.txt

Проверим, можем ли мы создавать файлы в расшареной папке с Дримбокса:
echo «Test from Dreambox» > /var/mnt/hdd/test_box.txt

Опять проверим командой ls :
ls -l /var/mnt/hdd

Удалим тестовые файлы:
rm /var/mnt/hdd/test.txt /var/mnt/hdd/test_box.txt

Размонтируем:
umount /var/mnt/hdd

Всё!!!

Сложно?

Да, чуть не забыл. Для постоянного монтирования строку:
Код:

Mount -t cifs -o rw,soft,udp,nolock,rsize=8192,wsize=8192,iocharset=utf8, user=abc,password=def //192.168.0.1/dreamshare /var/mnt/hdd

можно добавить в какой-нибудь стартовый скрипт Дримбокса, или поступить стандартно:
(для Gemini: Menu -> 6 -> 5 -> 1 -> Синяя кнопка )

IP компьютера = 192.168.0.1
Тип монтирования = CIFS
Директория = dreamshare
Локальная директория = /var/mnt/hdd
Опции = rw,soft,udp,nolock,iocharset=utf8
Екстра опции = nolock,rsize=8192,wsize=8192
USER = abc
PASSWORD = def
Automount = ДА (т.е. отметить галкой)

Ну сейчас точно Всё !!!

P.S. Этот метод тестировался и работает в Windows XP Pro, Windows XP Pro SP1, Windows XP Pro SP2. С Windows XP Pro SP3 и Window 7 не тестировался, но вероятнее всего также будет работать.

И запоминай … работа по CIFS и в Африке работа

1.3 Технологии CIFS и SMB

Общий протокол доступа к файлам Internet (Common Internet File System - CIFS) своим происхождением обязан технологии блока серверных со¬общений (Server Message Block - SMB), которая впервые появилась в MS DOS 3.3. В стандарте SMB описан протокол отправки команд файловой системы (открыть файл, считать, записать, блокировать и закрыть) от клиента к файловому серверу.
Перед обсуждением технических подробностей технологий CIFS и SMB необходимо выяснить основные различия между ними. Изначально существовала только технология SMB, которая использовалась в качестве клиент-серверного файлового протокола в мире персональных компьютеров. В середине 1980-х годов компания Microsoft дала своей реализации протокола SMB на¬звание CIFS и начала позиционировать CIFS в качестве прямого конкурента стандартов WebNFS и NFS. Компания Microsoft предоставила ознакомительный документ RFC на рассмотрение группе IETF (Internet Engineering Task Force), и впоследствии срок действия документа истек без попыток превратить RFC в одну из спецификаций IETF.
Независимые от компании Microsoft поставщики устройств NAS приступили к разработке спецификации CIFS и организовали несколько мероприятий для популяризации CIFS. Ассоциация SNIA (Storage Networking Industry Association) взяла на себя задачу публикации CIFS. Компания Microsoft также выпустила спецификацию CIFS (она называлась Common Internet Filesystem Access Protocol), распространявшуюся бесплатно.
В похожих друг на друга спецификациях SNIA CIFS и CIFS от компании Microsoft описывается протокол, используемый клиентами Windows NT 4.0 для получения доступа к ресурсам серверов Windows NT. В обеих спецификациях не рассматривается протокол SMB, который применяется в новых версиях Windows (например, не затрагивается клиентское кэширование, которое поддерживается в Windows 2000). Кроме того, в спецификациях не описаны все протоколы взаимодействия между серверами. Новый стандарт SMB, не относящийся к бесплатным спецификациям, описан в соответствующей спецификации, которая за определенную плату распространяется компанией Microsoft, что стало возможным благодаря судебным решениям Европейского Союза и правительства США.
Таким образом, компания Microsoft вновь стала называть свою реализацию описываемой технологии блоком SMB. По сути, SMB от Microsoft - это закрытый протокол, представляющий собой расширенную версию индустриального стандарта CIFS.
Кроме того, следует обратить внимание на историческую связь между SMB/CIFS и NetBIOS. Программный интерфейс NetBIOS (уровень сеанса в модели OSI) на данный момент безнадежно устарел. Интерфейс реализует уровень абстракции, который позволяет приложениям работать с различными транспортными протоколами, например TCP/IP, NetWare или уже забытым протоколом XNS (Xerox Network System). Необходимость в программном интерфейсе приложений, который предоставляет возможность создания приложений, не зависящих от сетевого протокола, существует и поныне. Од¬нако в настоящий момент для этого обычно используется интерфейс сокетов, в частности в мире Windows - интерфейс Winsock.
Компания Microsoft использовала NetBIOS для преобразования имен (пре¬образования имени сервера в сетевой адрес), но сейчас для этого предназначена стандартная служба DNS.
Изначально Microsoft не использовала TCP/IP в качестве транспортного протокола, что кардинально изменилось со временем, однако поддержка NetBIOS продолжала присутствовать. Тем не менее роль NetBIOS постоянно уменьшалась. После назначения порта TCP/IP для файловых серверов SMB зависимость от NetBIOS была полностью "излечена", по крайней мере в контексте базового протокола. Но ситуация оставалась запутанной, так как некоторым вторичным службам клиентов и серверов Windows все равно требовался протокол NetBIOS. Хорошим примером будет объявление серверами о своем присутствии в сети и предоставление списка доступных служб, а также передача этих объявлений клиентам другими серверами. Со временем службы были переделаны и NetBIOS был полностью снят со счетов с выходом Windows 2000.
Наконец, наследие SMB можно заметить в каждом запросе CIFS, поскольку каждый запрос и ответ должны начинаться со значение "0xFF", после чего следуют такие символы ASCII, как "SMB".

1.3.1 Разновидности стандарта CIFS

К сожалению, точного определения стандарта CIFS не существует. Различные типы протоколов SMB называются диалектами. Вот несколько воз¬можных вариантов:
■ применяемый клиентами DOS и Windows 3.x;
■ используемый при подключении к серверам, не работающим под управлением Windows;
■ применяемый клиентами под управлением Windows NT.
Чаще всего клиент отправляет серверу запрос на установку сеанса и передает список всех поддерживаемых вариантов протокола. Сервер выбирает наиболее функциональный вариант и отправляет клиенту соответствующий запрос. В зависимости от протокола, о котором "договорились" клиент и сервер, некоторые запросы и соответствующие им ответы могут быть недопустимыми. Согласованный вариант протокола не определяет однозначно фактическую реализацию функций протокола, что вносит еще большую путаницу; для указания поддержки определенных функций некоторые флаги могут быть установлены или сброшены. Другими словами, даже при выборе протокола существуют различные варианты предоставляемых функций: например, один из флагов может указывать на наличие поддержки длинных имен файлов.
Как описано в документе RFC компании Microsoft (по правилам IETF на данный момент он уже устарел), протокол CIFS обеспечивает взаимодействие клиента и сервера для доступа к файлам и управления ими. Такие функции, как объявление о наличии в сети доступных принтеров и серверов, выходят за рамки возможностей протокола CIFS.
Организация SNIA продолжает работу над спецификацией CIFS. Кроме того, SNIA проводит ежегодную конференцию, посвященную CIFS, и организует другие мероприятия, на которых обсуждаются вопросы взаимодействия систем по протоколу CIFS.
Спецификация SMB стала стандартом с 1992 года (X/Open CAE Specification С209) и описывает SMB как протокол для обеспечения взаимодействия между компьютерами под управлением DOS, Windows, OS/2 и UNIX.

1.3.2 Описание протокола CIFS

Запросы и ответы CIFS имеют четкую, понятную структуру. Поля пакетов SMB также стандартизированы, и отличия зависят от выбранной, разновидности CIFS и функций, поддерживаемых как клиентом, так и сервером.
Обратите внимание, что показаны только общие элементы для всех вариантов SMB. Подробности строения каждого варианта пакета SMB выходят за пределы тематики этой статьи.
Некоторые поля в таблице требуют более полного описания. Поле команды имеет размер в один байт и описывает тип запроса. Сервер копирует это значение в ответ, что позволяет клиенту анализировать последний. Спецификация CIFS содержит значения и определения для этого поля. Описанные команды позволяют выполнять такие операции, как открытие файла, чтение, запись и блокирование определенного диапазона файла. Все эти операции выполняются в качестве ответа на запрос приложения.
Кроме того, запросы клиента CIFS (и связанные с ними ответы сервера) инициируются кодом перенаправителя без явного вмешательства приложения. Примерами будут кэширование и оппортунистическая блокировка (opportunistic locking). В спецификациях CIFS RFC и SNIA, а также Open Group определены значения и семантика кода команды CIFS размером в 1 байт.

Таблица Структура заголовка SMB

Помните, что новые значения и семантика полей могут появиться без предупреждения с выходом новых версий Windows, так как протокол CIFS про¬должает развиваться.
Существует несколько команд для выполнения одинаковых базовых операций; например, для открытия, чтения и записи существует несколько раз личных команд. Некоторые команды уже не применяются, а в ряде случаев могут использоваться альтернативные команды, в зависимости от выбранного диалекта протокола.
Далее представлены примеры функций, описанных в поле команды.
■ Выбор типа SMB.
■ Установка сеанса связи.
■ Переход по каталогам и перечисление файлов и каталогов.
■ Открытие, создание, закрытие или удаление файлов.
■ Блокировка и разблокировка определенных фрагментов файла.
■ Операции печати.
■ Уведомления об изменении файлов и каталогов.
■ Транзакции, при которых указываются данные, параметры и операции. Сервер CIFS выполняет запрошенную операцию и возвращает результат - данные и параметры. Примерами транзакций могут служить ссылки в распределенной файловой системе и управление расширенными атрибутами.

Таблица Семантика поля Flags

В поле Flag2 описано еще больше необязательных функций. Значения этого поля приведены в таблице ниже.
Поле Заполнение/подпись изначально представляло собой последовательность "холостых" байт. Со временем значение этого поля изменилось. Поле заполнения теперь может включать в себя следующие элементы:

Таблица Семантика поля Flags2

■ 2 байта идентификатора процесса, что позволяет указывать 32-разрядные идентификаторы процесса;
■ 8 байт для хранения подписи пакета SMB, если эта функция активизирована (см. описание поля Flags2);
■ 2 неиспользуемых байта.

1.3.3 Безопасность CIFS

Протокол CIFS обеспечивает безопасность средствами сервера. Администратор может отключить систему встроенной безопасности CIFS, в чем едва ли появится необходимость, поэтому система безопасности включена по умолчанию.
В старых вариантах CIFS допускается отправка незашифрованного текстового пароля от клиента к серверу, что категорически не рекомендуется. Протокол CIFS допускает защиту ресурсов сервера с помощью паролей отдельных пользователей (это называется безопасностью на уровне пользователя). Для обеспечения обратной совместимости серверы CIFS поддерживают защиту общего ресурса на базе пароля, одинакового для всех пользователей. Поскольку ресурс будет предоставлен в общее пользование,- этот метод называется безопасностью на уровне ресурса. Использовать механизм безопасности на уровне ресурса не рекомендуется, и в Windows 2000 Server эта система отсутствует. Первый пакет SMB, который отправляется серверу клиентом, называется SMB_NEG0TIATE_PR0T0C0L. Пакет применяется для выбора типа CIFS. В ответ на запрос SMB_NEG0TIATE_PR0T0C0L сервер сообщает об используемом механизме безопасности (уровень пользователя или ресурса).
Начиная с Windows NT4 SP3 и Windows 2000, компания Microsoft предоставила возможность размещения в пакетах SMB цифровой подписи. Сервер может быть настроен на обязательное требование цифровой подписи от клиента; в противном случае клиенту будет запрещен доступ к ресурсам. Использование цифровой подписи отражается на производительности как сервера, так и клиента, но это цена, которую приходится платить за безопасность. Обратите внимание, что подписывание и проверка имеют двунаправленную природу, т.е. клиент подписывает отправляемые запросы, сервер проверяет подпись клиента и подписывает отправляемые ответы, после чего клиент проверяет подпись сервера. Подпись пакета SMB хранится в поле Заполнение/подпись.
Ответ на запрос SMB_NEG0TIATE_PR0T0C0L используется для предоставления клиенту информации о поддержке сервером подписывания пакетов SMB и о необходимости обязательного подписывания пакетов SMB.

1.3.4 Аутентификация CIFS

Протокол CIFS позволяет определять уровень безопасности при взаимодействии серверов и клиентов. Сервер может быть настроен на отказ в обслуживании клиентов, которые предлагают слишком низкий уровень безопасности.
Протокол CIFS предоставляет механизмы аутентификации, необходимые серверу для аутентификации клиента. Кроме того, предоставляются методы аутентификации сервера клиентом. В базовом уровне аутентификации клиент сообщает имя пользователя и незашифрованный пароль. По очевидным причинам такой подход нежелателен. Более того, сервер можно настроить на отказ в обслуживании клиентов, которые отправляют пароли в незашифрованном виде.
Аутентификация может выполняться с помощью технологии, которая называется протокол запрос/ответ (challenge/response protocol). При отправке клиентом пакета SMB_NEGOTIATE_PROTOCOL для выбора типа CIFS флаг в ответе сервера указывает на возможность использования протокола запрос/ответ. Если сервер поддерживает этот протокол, в ответе сервера предоставляется 8-байтовый запрос. Запрос - это случайное значение с очень низкой вероятностью повторной генерации. И клиент и сервер формируют ключ из пароля пользователя. После этого запрос шифруется с помощью ключа и алгоритма DES (Data Encryption Standart). Клиент отправляет запрос серверу, а сервер сравнивает ответ с собственным подсчитанным значением. Если два значения совпадают, клиент доказывает знание пароля и подтверждает свою аутентичность.
Кроме того, протокол CIFS поддерживает систему расширенной безопасности (можете и не надеяться, что читатель, который догадается об указании на поддержку расширенной безопасности в ответе сервера на запрос SMB_NEGOTIATE_PROTOCOL, получит награду). Механизм расширенной безопасности предоставляет возможность поддержки произвольного протокола аутентификации в рамках протокола CIFS. При выборе расширенной безопасности первый двоичный объект безопасности предоставляется в ответе на запрос SMB_NEGOTIATE_PROTOCOL. Двоичные объекты безопасности не обрабатываются протоколом CIFS. В этом он полагается на механизмы клиента и сервера, предназначенные для генерации и обработки двоичных объектов. Последующие двоичные объекты безопасности могут передаваться с данными SMB.
Использование механизма расширенной безопасности позволило Microsoft обеспечить поддержку протокола Kerberos в Windows 2000 и более поздних версиях. Реализация Kerberos в Windows 2000 является примером использования закрытых элементов. Например, некоторые поля мандатов Kerberos применяются для передачи информации о группах, в которые входит клиент. Реализация Kerberos от Microsoft допускает взаимную аутентификацию, когда не только сервер проводит аутентификацию клиента, но и наоборот, клиент аутентифицирует сервер.
Компания Microsoft предлагает еще один способ установки сеанса связи между клиентом и сервером, который называется Netlogon. При этом используются данные о компьютере (а не о пользователе). Протокол Netlogon необходим для установки безопасного сеанса RPC и имеет намного больше возможностей, так как поддерживает маркеры доступа пользователей, которые не поддерживаются при регистрации средствами протокола CIFS. Обычно Netlogon используется для связи между серверами (один сервер выступает в роли клиента другого сервера).
Наконец, сервер CIFS не обязательно должен обеспечивать работу механизма аутентификации. Протокол CIFS поддерживает сквозную аутентификацию, когда сервер получает запрос у другого сервера, передает этот запрос клиенту и возвращает ответ клиента серверу аутентификации. При этом, если сервер аутентификации отвечает положительно, клиенту предоставляется доступ к запрошенным ресурсам. Этот механизм известен как сквозная аутентификация.

1.3.5 Возможности по оптимизации CIFS

Протокол CIFS обладает различными возможностями по оптимизации взаимодействия между клиентом и сервером.

1.3.5.1 Функция CIFS AndX

Протокол CIFS позволяет формировать последовательность взаимно зависящих друг от друга запросов, поэтому оптимизация этих операций позволяет завершить выполнение запроса за одно обращение к серверу. Эта функция называется AndX; Файловая система NFS версии 4 обеспечивает подобную функцию в виде процедуры COMPOUND. Примером может быть отправка запросов OpenAndRead или WriteAndClose серверу CIFS. При этом вместо отправки отдельных двух запросов, например Open, а затем Read, и получения двух ответов отправляется один запрос OpenAndRead и получается один ответ. Это имеет особое значение в том случае, когда время обращения запрос/ответ слишком велико.

1.3.5.2 Оппортунистическая блокировка

Протокол CIFS поддерживает такую технологию оптимизации производительности, как оппортунистическая блокировка (opportunistic locking, или oplock). Существует две основные причины для использования оппортунистической блокировки.
Первая заключается в блокировке файла и инициализации его локального кэширования. Когда условие блокировки больше не может поддерживаться, протокол допускает определенную задержку, в течение которой клиент должен очистить кэш. Блокировка и разблокировка выполняются незаметно для приложения с помощью механизмов CIFS клиентской и серверной систем. При этом для повышения производительности модификации приложения не требуется.

Представьте себе приложение, которое открывает файл на сетевом сервере для чтения и записи и записывает в файл 128-байтовые записи. Без оппортунистической блокировки каждая запись размером 128 байт потребует передачи данных по сети. Использование oplock позволяет локально кэшировать файл на клиентской системе и объединять несколько операций записи в одну, которая приводит к передаче данных по сети. Например, предположим, что клиент использует буферы размером 4096 и последовательно записывает в файл по 128 байт. Первый буфер будет содержать данные 32 операций записи (4096/128 = 32), и все данные 32 записей будут переданы по сети одним запросом на запись в файл. Если операция записи не может быть кэширова-на, по сети будет передаваться 32 операции записи (а не одна, как при кэшировании). Сокращение количества операций записи с 32 до одной приводит к значительному снижению нагрузки на сеть и существенному повышению производительности.
Вторым назначением оппортунистической блокировки является расширение условий, при которых подобная блокировка возможна. При использовании oplock можно увеличить эффективность кэширования. Расширение условий, при которых возможна оппортунистическая блокировка, предоставляет несколько дополнительных преимуществ. Предположим, что экземпляр при¬ложения открывает файл (на сетевом сервере) для чтения и записи. При этом запрашивается и предоставляется оппортунистическая блокировка. Программный код клиента может кэшировать операции записи в файле. Предположим, что другой экземпляр того же приложения запущен на другом клиенте. Одним из выходов из подобной ситуации будет снятие оппортунистической блокировки и использование сетевого ввода-вывода для передачи запросов на запись в файл от обоих приложений. Еще одним способом бу¬дет снятие оппортунистической блокировки в тот момент, когда второй экземпляр приложения попытается выполнить операцию записи. Очень часто приложения вообще не выполняют операции записи.
При изменении условий сервер отправляет уведомление клиенту о снятии оппортунистической блокировки. В качестве примера ситуации, когда сервер отправляет уведомление о снятии оппортунистической блокировки, можно указать запрос на доступ к файлу или запись данных в файл другим клиентом. Сервер обеспечивает очистку данных состояния сервера (включая закрытие сеанса клиента), если клиент не отвечает на запрос о снятии оппортунистической блокировки. Клиент запрашивает oplock только в случае необходимости; например, если приложение запрашивает открытие файла для эксклюзивного доступа, запрос оппортунистической блокировки просто не имеет смысла.
Оппортунистические блокировки реализуются в трех вариантах:

Последовательность операций при эксклюзивной оппортунистической блокировке

■ эксклюзивная оппортунистическая блокировка;
■ пакетная оппортунистическая блокировка;
■ оппортунистическая блокировка второго уровня. Далее эти сценарии описываются более подробно.

Эксклюзивная оппортунистическая блокировка

Этот вариант блокировки запрашивается мини-перенаправителем CIFS, когда приложение открывает файл для чтения или записи. Сервер предоставляет оппортунистическую блокировку, если файл еще не открыт другим клиентом. Последовательность операций показана на рисунке.
Для начала первый клиент отправляет запрос на открытие файла, запрашивая эксклюзивную оппортунистическую блокировку. Сервер выполняет необходимую проверку и предоставляет ее. Первый клиент начинает кэширование файла, выполняя операции упреждающего чтения и отложенной записи. Через некоторое время другой клиент, например клиент 2 отправляет серверу запрос на открытие того же файла. Сервер отмечает, что клиент 1 владеет эксклюзивной оппортунистической блокировкой для запрошенного файла, и отправляет уведомление о снятии блокировки клиенту 1. Клиент 1 очищает буферы данных, отправляя необходимые запросы на запись и на блокировку файла. Как только данные состояния файла будут записаны, клиент 1 сообщает серверу, что обработка уведом¬ления о снятии оппортунистической блокировки завершена. На этом этапе сервер отправляет ответ клиенту 2, позволяя ему открыть файл. Клиент 1 продолжает работу с файлом, не проводя при этом локального кэширования. В данном случае предполагается, что клиент 1 открыл файл в режиме, допускающем открытие файла другими клиентами.

Оппортунистическая блокировка второго уровня

Очень часто клиенты открывают файл в режиме чтения/записи и ничего не записывают в файл до его закрытия. Оппортунистическая блокировка второго уровня проектировалась для обеспечения совместного использования и кэширования файлов в такой ситуации. Эксклюзивная оппортунистическая блокировка и пакетная оппортунистическая блокировка (она рассматривается в следующем разделе) всегда предоставляются по запросу клиента. Но оппортунистическая блокировка второго уровня никогда не запрашивается клиентом. Клиент начинает с запроса эксклюзивной оппортунистической блокировки. Если такая блокировка предоставляется, сервер при выполнении определенных условий (они описаны далее) может понизить эксклюзивную оппортунистическую блокировку до блокировки второго уровня.
Клиент 1 начинает работу с запроса эксклюзивной оппортунистической блокировки и приступает к локальному кэшированию файла. В частности, клиент 1 проводит упреждающее чтение и локально кэширует блокируемые данные. Помните, что в данном случае клиент не собирается записывать данные в файл. На определенном этапе клиент 2 запрашивает доступ к этому же файлу. Сервер отправляет клиенту 1 уведомление с требованием понизить эксклюзивную оппортунистическую блокировку до блокировки второго уровня. Клиент аннулирует блокировки и сообщает, что обработка уведомления завершена. Далее серь вер отправляет клиенту 2 сообщение об успешном открытии файла и предоставляет клиенту оппортунистическую блокировку второго уровня. В данном случае предполагается, что клиент 1, открывая файл, сообщил серверу, что другие клиенты также могут получить доступ к файлу.
При использовании оппортунистической блокировки второго уровня, клиентам запрещено буферизировать блокируемые данные. Преимущество этой схемы заключается в упрощенной когерентности данных на стороне сервера, в то время как клиент будет кэшировать считываемые данные, что позволяет сократить объем информации, передаваемой по сети. Как только один из клиентов выдает запрос на запись, сервер снимает оппортунистическую блокировку второго уровня, после чего блокировок вообще не остается. Поскольку ни один из клиентов не буферизирует блокируемые данные при на¬личии блокировок второго уровня, успешная операция записи означает, что запись выполнялась в область файла, не заблокированную другими клиента¬ми. После снятия оппортунистической блокировки второго уровня клиентам запрещается буферизировать считанные данные.

Оппортунистическая блокировка второго уровня

Пакетная оппортунистическая блокировка

Этот вариант блокировки используется для оптимизации быстродействия при обработке командных файлов. Командный процессор обычно открывает файл, ищет необходимую строку, считывает ее, закрывает файл и обрабатывает прочитанную строку средствами интерпретатора командной строки. После этого файл открывается снова, в нем находится следующая строка, файл закрывается, и следующая строка обрабатывается интерпретатором командной строки. Этот цикл выполняется, пока все строки в командном файле не закончатся.

Пакетная оппортунистическая блокировка

Выше приведена последовательность операций. Клиент 1 открывает командный файл и запрашивает пакетную оппортунистическую блокировку. Предположим, что сервер предоставляет пакетную блокировку, так как больше никто не выполняет запись данных в файл. Клиент 1 ищет в файле определенную строку и осуществляет операцию чтения. Интерпретатор выполняет прочитанную строку. Затем файл закрывается. Мини-перенаправитель CIFS не выполняет никаких действий при получении запроса на закрытие файла (т.е. выполняется операция отложенного закрытия). Интерпретатор командной строки открывает файл, но мини-перенаправитель CIFS не выполняет операцию открытия, а просто отменяет размещенную в очереди операцию отложенного закрытия файла. Когда интерпретатор командной строки выполняет операции поиска и чтения строки, мини-перенаправитель CIFS отправляет запросы на поиск и чтение.
В результате сокращается объем данных, передаваемых по сети (выполняется меньше запросов на открытие и закрытие файла). Кроме того, оптимизируется использование ресурсов сервера, так как от сервера не требуется немедленной обработки запроса на закрытие файла с последующим его повторным открытием.

Изучаем Linux, 302 (смешанные среды)

Интеграция с протоколом CIFS

Использование Linux в качестве клиента серверов SMB/CIFS

Серия контента:

Об этой серии

Эта серия статьей поможет вам освоить задачи администрирования операционной системы Linux. Вы можете использовать материалы этих статей для подготовки к экзаменам программы LPIC третьего уровня (LPIC-3) .

Чтобы посмотреть описания статей этой серии и получить ссылки на них, обратитесь к нашему . Этот перечень постоянно дополняется новыми статьями по мере их готовности и содержит текущие (по состоянию на ноябрь 2010 года) цели экзаменов сертификации LPIC-3.

В этой статье рассматриваются следующие темы:

• Протоколы Server Message Block (SMB) и Common Internet File System (CIFS).
• Возможности и преимущества использования CIFS.
• Монтирование общих файловых ресурсов CIFS на клиентах Linux.

Эта статья поможет вам подготовиться к сдаче экзамена LPI 302 (специализация "Смешанные среды") и содержит материалы цели 314.1 темы 314. Цель имеет вес 3.

Предварительные требования

Чтобы извлечь наибольшую пользу из наших статей, необходимо обладать продвинутыми знаниями о Linux и иметь работоспособный компьютер с Linux, на котором можно будет выполнять все встречающиеся команды. В частности, предполагается, что читатель умеет работать с командной строкой Linux, знает основы конфигурирования Samba и имеет общее представление о структуре конфигурационного файла smb.conf. Необходимо также знать основы монтирования локальных и удаленных файловых систем (с помощью команды mount и файла /etc/fstab). Знания о команде ftp , входящий в стандартный набор текстовых команд Linux приветствуются, хотя не являются обязательными.

Что такое SMB/CIFS

О факультативном экзамене LPI-302

Как и многие другие программы, программа сертификации Linux Professional Institute (LPIC) предусматривает различные уровни сертификации, где для получения каждого последующего уровня необходимо обладать более глубокими знаниями и практическим опытом. Экзамен LPI-302 – это факультативный экзамен третьего уровня программы LPIC, требующий продвинутых знаний в области системного администрирования Linux.

Для получения сертификата LPIC третьего уровня (LPIC-3) необходимо успешно сдать два экзамена первого уровня (101 и 102), два экзамена второго уровня (201 и 202), а также базовый экзамен 301 третьего уровня (LPIC-3). Если вы получили сертификат третьего уровня, вы можете сдавать факультативные экзамены по определенным специализациям, например, экзамен LPI-302.

Прежде чем переходить к рассказу о том, как использовать Linux в качестве клиента сервера SMB/CIFS, полезно рассказать об особенностях этих протоколов и выяснить, насколько полно они обеспечивают использование файловой системы при работе с Linux . Мы объясним, как работает изучение оригинальный протокол SMB и какие новые функции реализованы в его модификации CIFS . Вы можете обратиться к статье developerWorks, содержащей материалы цели 310.1 экзамена LPI, в которой рассматриваются некоторые основные принципы SMB/CIFS (см. ссылку в разделе ).

Основные возможности SMB

SMB обладает несколькими уникальными возможностями с точки зрения работы в сети, включая собственную систему именования компьютеров (Network Basic Input/Output System, NetBIOS), рабочие группы и протоколы аутентификации. Для того чтобы понять, как SMB и CIFS работают с Linux-клиентами общих файловых ресурсов, нужно рассказать о наиболее важной функции этих протоколов, а именно, о наборе предоставляемых ими метаданных.

Метаданные – это данные, связанные с файлом, но не являющиеся его частью. Примером метаданных являются метка времени, владелец, права доступа и даже имя файла. Несомненно, вы знаете о некоторых способах использования метаданных на компьютерах Linux и, возможно, об их некоторых отличиях в Linux и других операционных системах, например, Windows. Поскольку протокол SMB был разработан для DOS, Windows и IBM Operating System/2® (OS/2), то он содержит много метаданных, специфичных для этих операционных систем. Однако более важно то, что SMB не поддерживает такие метаданные UNIX® и Linux, как владельцы, группы и большинство прав доступа. Кроме того, SMB не поддерживает символические и жесткие ссылки, а также другие специальные типы файлов, такие как файлы устройств. SMB содержит несколько типов метаданных, не распознаваемых Linux в обычном режиме, например, биты hidden (скрытый) , archive (архивный) и system (системный). Бит Read-only (только чтение) можно сопоставить биту разрешений Write (запись) в Linux.

Создайте ваш собственный канал

Вы можете создать ваш собственный RSS, Atom или HTML канал обновлений и получать уведомления о новых или обновленных статьях нашего сайта. Для этого перейдите на страницу , выберите зону Linux , установите флажок Статьи и введите в качестве ключевой фразы Linux Professional Institute , после чего выберите требуемый тип канала.

Другим ограничением SMB является максимальный размер файла, равный двум гигабайтам. Это ограничение является очевидной проблемой в сегодняшнем мире многогигабайтовых архивов, мультимедиа-файлов и т. д.

Для того чтобы клиенты Linux могли работать с SMB с учетом вышеперечисленных особенностей, они должны либо игнорировать их, либо иметь возможность использовать "поддельные" данные. Эти возможности похожи на те, что используются при монтировании в Linux файловых систем NTFS или FAT. К счастью, протокол CIFS предоставляет более широкий набор инструментов, позволяющих обходить некоторые из этих ограничений.

Необходимо также знать и о сетевых портах, используемых протоколом SMB. Это UDP-порты (User Datagram Protocol) 137 и 138, а также TCP-порт 139 (службы сеансов – другими словами, передача файлов). Эта информация потребуется при отладке SMB с помощью низкоуровневых утилит диагностики сети.

Расширения CIFS для протокола SMB

В середине 1990-х годов компания Microsoft® изменила название протокола SMB на CIFS и одновременно добавила в него ряд новых возможностей, включая поддержку символических и жестких ссылок, а также файлов большого объема. Также CIFS поддерживает доступ к серверу по защищенному TCP-порту 445 в дополнение к стандартному порту 139.

Не менее важными, чем собственные расширения Microsoft для SMB, оказались и другие расширения CIFS. В частности, ряд функциональных возможностей, известный как UNIX extensions (расширения UNIX), обеспечивает поддержку владельцев и прав доступа к файлам наряду с другими типами метаданных UNIX. Если и клиенты, и сервер поддерживают эти расширения, то использование протокола CIFS вместо протокола SMB может обеспечить намного более эффективную работу клиентов под управлением Linux. Как и можно было ожидать, эти расширения не поддерживаются операционными системами семейства Windows Server®, поэтому полезны они только тогда, когда клиенты Linux подключаются к серверу Samba. Сервер должен быть настроен с помощью следующего глобального параметра:

По умолчанию этот параметр был установлен в No во всех версиях Samba, меньше 3.0, но в Samba 3.0 по умолчанию он установлен в Yes , что избавляет от необходимости настраивать его вручную.

Использование smbclient

Возможно, самый простой способ получить доступ к серверу SMB/CIFS с клиента Linux – это использовать утилиту командной строки smbclient . Эта утилита похожа на классическую команду ftp , поэтому если вы знакомы с ftp , то вы легко освоите и smbclient . Если вы не знакомы с ftp , то достаточно знать, что эта программа обеспечивает соединение с сервером без стандартного монтирования общих файловых ресурсов. Вместо этого для просмотра, удаления, загрузки или передачи файлов пользователь выполняет различные команды.

Для использования smbclient необходимо набрать в командной строке имя этой команды и имя службы в следующем формате: // СЕРВЕР / СЛУЖБА . Например, если необходимо получить доступ к общему ресурсу GORDON на сервере TANGO, то следует указать имя //TANGO/GORDON . В зависимости от конфигурации сервера может потребоваться ввести пароль. Если введен правильный пароль, то можно вводить различные команды для доступа к файлам, хранящимся на сервере. В таблице 1 перечислены некоторые наиболее важные команды smbclient ; для получения информации о других более экзотических командах обратитесь к man-странице этой утилиты.

Таблица 1. Наиболее важные команды smbclient

По умолчанию для подключения к серверу smbclient использует текущее имя пользователя, однако можно указать имя явно с помощью опции -U . На самом деле, можно использовать несколько опций командной строки, включая опции, позволяющие передавать файлы без входа в интерактивный режим smbclient . Таким образом, smbclient можно использовать в сценариях для выполнения автоматической передачи файлов. За дополнительной информацией обратитесь к man-странице этой утилиты.

Сеанс работы с smbclient выглядит примерно следующим образом:

Листинг 1. Пример сеанса работы с smbclient

Совет. Утилита smbclient является превосходным инструментом отладки. Не смотря на свою простоту, она позволяет получить доступ к сетевому окружению без монтирования ресурсов, что может упрощает поиск и устранение проблем.

Монтирование файловых ресурсов SMB/CIFS

Не смотря на всю свою эффективность, smbclient не позволяет получить такой же прозрачный доступ к серверу, как при работе с Windows-клиентом. Если вам необходим именно такой доступ, то необходимо использовать другие средства, позволяющие монтировать общие ресурсы SMB/CIFS. Это можно сделать с помощью стандартной команды Linux mount или редактируя файл /etc/fstab для автоматического монтирования ресурсов SMB/CIFS при загрузке компьютера.

Временное монтирование общих ресурсов

Файловый ресурс SMB/CIFS можно смонтировать с помощью команды mount , которая также используется для монтирования локальных томов или совместно используемых ресурсов NFS. Можно указать тип файловой системы cifs или в большинстве случаев mount определит необходимость использования того или иного драйвера на основе синтаксиса команды. Кроме того, можно напрямую вызвать вспомогательную программу mount.cifs . По сути, монтирование локальной и удаленной файловой системы отличается лишь типом монтируемого устройства; таким образом, для монтирования ресурса GORDON, расположенного на сервере TANGO, достаточно выполнить от имени пользователя root следующую команду:

На практике такая команда может создать проблему: в качестве имени пользователя она передает на сервер имя root , и если этому пользователю не разрешено подключаться к серверу, то монтирование завершится с ошибкой. Эту проблему можно исправить, используя опцию -o user=имя для передачи имени пользователя на сервер.

Можно использовать несколько других опций монтирования, передаваемых команде mount с помощью опции -o . Наиболее полезные из них перечислены в таблице 2. За дополнительной информацией об остальных опциях обратитесь man-странице mount.cifs .

Таблица 2. Наиболее важные опции mount.cifs

Параметры uid , gid , file_mode и dir_mode обычно не являются обязательными при подключении к серверу с поддержкой расширений UNIX, реализованных в CIFS. Тем не менее, эти параметры можно использовать для переопределения значений, установленных на сервере. Также отметим, что все эти параметры влияют на то, как файлы видны клиенту ; они не влияют на разрешения и права владения файлами на сервере.

После того, как общий ресурс SMB/CIFS смонтирован, можно получить к нему доступ точно так же, как и к локальному диску или тому NFS. Можно копировать и удалять файлы командами cp и rm , редактировать их в текстовых редакторах или других программах и т. д. Однако помните о том, что если сервер не поддерживает определенные возможности, то вы не сможете их использовать. Например, невозможно изменить режим файла с помощью chmod , если сервер не поддерживает расширения UNIX (частным исключением в случае с chmod является возможность изменения разрешений на запись – эти разрешения инверсно сопоставлены биту "только чтение" протокола SMB).

Когда работа с общим ресурсом закончена, его можно размонтировать с помощью команды umount , как обычную локальную файловую систему:

Монтирование файловых ресурсов с помощью SMB

Ядра Linux до версии 2.6.37 содержали отдельные драйверы SMB и CIFS и позволяли смонтировать общий ресурс с использованием оригинальных протоколов SMB; для этого нужно было либо указать в качестве типа файловой системы smbfs , либо использовать команду smbmount . При этом все работало почти так же, как и при использовании типа файловой системы cifs или команды mount.cifs , хотя имелись некоторые отличия в деталях. Использование протокола SMB делало невозможным использование функций, присущих только CIFS, например, расширений UNIX.

Раньше иногда имело смысл использовать SMB; например, можно было монтировать файловые ресурсы очень старых компьютеров под управлением Windows 9x/Me, используя драйвер Linux smbfs , но не используя cifs . Сегодня такие ситуации встречаются очень редко, поскольку в современной реализации cifs была устранена бо льшая часть его когда-то существовавших ограничений. Тем не менее, если вы столкнулись с подобной проблемой, то попробуйте инсталлировать ядро Linux с версией до 2.6.37 и проверить, поможет ли драйвер smbfs решить ее.

Постоянное монтирование общих ресурсов

Если необходимо смонтировать файловый ресурс SMB/CIFS на постоянной основе, то для этого нужно добавить запись в файл /etc/fstab. Эти изменения похожи на все другие изменения файла /etc/fstab, которые возникают в процессе работы команды mount . Однако в есть одна опция, которая заслуживает особого внимания в данной ситуации, а именно credentials . Поскольку большинство SMB/CIFS серверов используют для аутентификации пароли, то для монтирования файловых ресурсов с помощью /etc/fstab необходимо хранить постоянный пароль. Хотя пароль можно хранить непосредственно в файле /etc/fstab (используя опцию password), делать этого не рекомендуется – поскольку файл /etc/fstab должен быть доступен для чтения всем пользователям, то любой пользователь может также увидеть и пароль. Использование опции credentials позволяет хранить пароли в файле, доступном для чтения только пользователю root, что повышает их защищенность.

Рабочая запись в файле /etc/password для общего ресурса SMB/CIFS может выглядеть следующим образом:

Связанные с ней учетные данные могут выглядеть так: