* [Comm] CIFS vs SMB
@ 2007-03-29 9:55 Alexander Yereschenko
2007-03-29 10:54 ` Sergey Vlasov
0 siblings, 1 reply; 3+ messages in thread
From: Alexander Yereschenko @ 2007-03-29 9:55 UTC (permalink / raw)
To: community
Доброе!
Столкнулся с такой проблемой:
сервер - ALC3.0.4 + updates +backports
клиент - февральский сизиф (на alc3 наблюдалось то же самое)
На сервере ресурс:
===
[Doc]
comment = Documents
path = /home/Doc
valid users = @z-doc
write list = @z-doc
force group = z-doc
read only = no
create mask = 0664
force create mode = 0664
directory mask = 0775
case sensitive = no
msdfs proxy = no
force directory mode = 0775
guest ok = no
===
Подключаем на клиенте ресурс Doc по протоколу SMB (через smb4k) - все
красиво, но при копировании в любую сторону большого объема данных (типа
фильм, либо сравнимую по объему кучу мелких файлов) происходит отвал. При
этом на клиенте ресурс считается подмонтированным, но доступа к нему нет.
Приходится рутом отмонтировать...
То же там же подключаем по протоколу CIFS - отвалов нет, но отсутствует
обещанный доступ по записи.
В логе сервера:
(юзер youz - uid=513, группа z-doc - gid=505 , youz в группу z-doc входит)
===
[2007/03/27 15:09:39, 1] smbd/service.c:make_connection_snum(642)
dron.zetetika.ltd (192.168.0.51) connect to service Doc initially as user
youz
(uid=513, gid=505) (pid 9259)
[2007/03/27 15:09:39, 0] smbd/trans2.c:call_trans2setfsinfo(2093)
set_user_quota: access_denied service [Doc] user [youz]
===
Никаких квот не настраивал - все по-умолчанию...
Для сравнения на том же сервере доступ к ресурсу Temp по протоколу CIFS
проходит "на ура" (на SMB все так же падает):
===
[Temp]
comment = Temporary
path = /home/Temp
write list = @z-temp
force group = z-temp
create mask = 0666
force create mode = 0666
directory mask = 0777
guest ok = yes
case sensitive = no
msdfs proxy = no
force directory mode = 0777
hide dot files = no
===
Если клиент - оффтопиковская ХР - то все нормально (по какому протоколу она
лезет? )
Итак, как сделать надежно, без падений и чтобы честно отрабатывались права?
1) SMB - оно действительно падучее?
2) CIFS - как настроить, чтобы честно отрабатывались права доступа (в
частности надо чтобы к ресурсу имели доступ не все даже по чтению)
--
Alexander
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Comm] CIFS vs SMB
2007-03-29 9:55 [Comm] CIFS vs SMB Alexander Yereschenko
@ 2007-03-29 10:54 ` Sergey Vlasov
2007-03-29 11:30 ` Alexander Yereschenko
0 siblings, 1 reply; 3+ messages in thread
From: Sergey Vlasov @ 2007-03-29 10:54 UTC (permalink / raw)
To: community
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
On Thu, Mar 29, 2007 at 12:55:59PM +0300, Alexander Yereschenko wrote:
> Столкнулся с такой проблемой:
> сервер - ALC3.0.4 + updates +backports
> клиент - февральский сизиф (на alc3 наблюдалось то же самое)
[...]
> Подключаем на клиенте ресурс Doc по протоколу SMB (через smb4k) - все
> красиво, но при копировании в любую сторону большого объема данных (типа
> фильм, либо сравнимую по объему кучу мелких файлов) происходит отвал. При
> этом на клиенте ресурс считается подмонтированным, но доступа к нему нет.
> Приходится рутом отмонтировать...
smbfs в ядре сейчас фактически не поддерживается, и даже ведутся
разговоры о том, чтобы убрать её из ядра.
> То же там же подключаем по протоколу CIFS - отвалов нет, но отсутствует
> обещанный доступ по записи.
Наиболее часто встречающаяся проблема с cifs связана с тем, что cifs
пытается использовать расширения протокола CIFS для UNIX, если сервер
их поддерживает, однако для правильной работы в этом случае
необходимо, чтобы значения uid и gid на сервере и на клиенте совпадали
(подразумевается, что будет использоваться либо NIS, либо что-то типа
nss_ldap). Причём опции монтирования для отключения UNIX Extensions у
cifs нет, поэтому приходится отключать их со стороны сервера:
[global]
unix extensions = no
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Comm] CIFS vs SMB
2007-03-29 10:54 ` Sergey Vlasov
@ 2007-03-29 11:30 ` Alexander Yereschenko
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Yereschenko @ 2007-03-29 11:30 UTC (permalink / raw)
To: community
В сообщении от 29 марта 2007 13:54 Sergey Vlasov написал(a):
> Наиболее часто встречающаяся проблема с cifs связана с тем, что cifs
> пытается использовать расширения протокола CIFS для UNIX, если сервер
> их поддерживает, однако для правильной работы в этом случае
> необходимо, чтобы значения uid и gid на сервере и на клиенте совпадали
> (подразумевается, что будет использоваться либо NIS, либо что-то типа
> nss_ldap). Причём опции монтирования для отключения UNIX Extensions у
> cifs нет, поэтому приходится отключать их со стороны сервера:
>
> [global]
> unix extensions = no
О! То, что надо! Спасибо! Заработало как хотелось.
Чувствовал, что где-то здесь кроется... Но перекопать весь man smb.conf не
сподвигнулся... :)
--
Alexander
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-03-29 11:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-29 9:55 [Comm] CIFS vs SMB Alexander Yereschenko
2007-03-29 10:54 ` Sergey Vlasov
2007-03-29 11:30 ` Alexander Yereschenko
ALT Linux Community general discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 community community/ http://lore.altlinux.org/community \
mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com
public-inbox-index community
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.community
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git