Больше полугода назад перевел файл- и прокси-серверы в небольшой компании с оффтопика на Ubuntu. Работать стало шустрее, особенно прокся. На файл-сервере, который по совместительству еще и принт-сервер, иногда "подвисает" CUPS, когда на него шлют особенно кривой документ. Виндовый диспетчер очереди печати у старого сервера в таких случаях просто падал. Здесь же я скриптик для лечения проблемы вывел на веб-морду сервера и дал туда доступ избранным юзерам. Короче, у юзеров оффтопик, на серверах - Ubuntu. Идиллия.
Проблема возникла, когда зам. ген. директора, попав под мое влияние, попросил установить ему на компутер Ubuntu-десктоп: на текущий момент мне не удалось полноценно подружить SAMBA-файл-сервер с SAMBA-клиентом на стороне Ubuntu-десктоп.
Здесь придется сделать небольшое отступление в сторону конфигурации SAMBA-сервера: Все юзеры разбиты на группы по отделам. Каждая группа имеет свой каталог, куда она может писать, в каталогах других групп она может только читать. Есть каталог, где могут писать и читать все юзеры и который автоматически очищается каждую ночь (типа, обменник). Технически это реализовано так:
- для каждого отдела заведена своя системная группа;
- для каждого юзера создана системная учетная запись;
- каждая системная учетная запись введена в одну или несколько групп;
- для каждого юзера созданы учетные записи Samba;
- для каждого отдела в корне шары создан каталог, владельцем которого сделан юзер root и группа, соответствующая отделу, и поставлен флаг "set group ID" (когда юзер создает файл в каталоге своего отдела, он становится юзером-владельцем файла, а группой владельца благодаря "set GID" остается группа отдела, так что другие юзеры в пределах отдела могут изменять файлы без ограничений). ACL не используются.
Все вышеописанное замечательно работает, если SAMBA-клиентом является Windows 2000/XP. С Ubuntu Desktop же это, на удивление, работать не хочет. Монтировать шару пытаюсь так (делаю через fstab, мануалов в сети достаточно):
//<server_ip>/Main /mnt/main smbfs username=Alioth,password=badpassword,auto,user,rw,iocharset=utf8 0 0
//<server_ip>/Main /mnt/main cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
с различными вариациями. Если указать неверный логин или пароль, то, понятно, на сервер оно вообще не пускает. А вот если логин и пароль правильные, то запись возможна только в каталог, куда можно писать всем. Каталоги отделов, даже если юзер Alioth принадлежит соответствующим группам, доступны только на чтение. То есть в наутилусе пункты создания папки и пустого документа - серые. Если полезть в эти каталоги терминалом и сделать "touch a.txt", то оно говорит "Permission denied". Но! Если сделать "sudo touch a.txt", то файл создается. А после "gksudo nautilus", он ведет себя с теми же полномочиями на шаре, как и виндовый проводник. То есть претензий тогда нет. Но ведь запускать nautilus и весь другой софт от рута, чтобы он нормально работал на шаре - не кошерно?!
Еще думал, что надо локального юзера в убунте сделать членом какой-то специальной группы для нормального доступа к шаре, но вроде никаких подозрительных групп в Ubuntu-десктоп не нашлось.
Гуглил отчаянно, но ничего толкового не нагуглил.
Люди! Подскажите, в какую сторону копать?
P.S.: Файлы конфигурации и логов SAMBA с сервера не привожу, ибо, похоже, проблема на стороне клиента. В логах на сервере все чисто, кроме разве что такой ошибки:
[2009/07/02 17:22:24, 0] lib/util_sock.c:read_data(534) read_data: read failure for 4 bytes to client <client_ip>. Error = Connection reset by peer
но эта ошибка была лишь один раз и, видимо, с проблемой не связана.
Тема: SAMBA-сервер vs. SAMBA-клиент (Прочитано 1763 раз)
