veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/
в конфиге самбы может помочь...

но на самом деле из-за этой проблемы в свое время перешли на sql...

У меня базы 1С лежат на самбе с почти дефолтными настройками. Есдинственное, что добавил, это

csc policy = disable

Вот весь конфиг:

[global]
        # Main settings
        netbios name = Server
        workgroup = CALOCAL
        server string =

        interfaces = lo, brlan
        bind interfaces only = Yes

        socket options = IPTOS_LOWDELAY TCP_NODELAY

        wins support = Yes
        dns proxy = No

        time server = Yes

        domain logons = Yes
        preferred master = Yes

        utmp = Yes

        logon home =
        logon path =
        template homedir =

        logon script = logon.bat

        load printers = No
        printing = bsd
        printcap name = /dev/null
        disable spoolss = yes

        passdb backend = ldapsam:ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock
        ldap admin dn = cn=ldapadmin,dc=calocal
        ldap suffix = dc=calocal
        ldap user suffix = ou=Users
        ldap group suffix = ou=Groups
        ldap machine suffix = ou=Machines
        ldap idmap suffix = ou=Idmaps
        ldap passwd sync = Only

        add machine script = /usr/sbin/ldapaddmachine '%u' smb-domain-computers
        add user script = /usr/sbin/ldapadduser '%u' smb-domain-users
        add group script = /usr/sbin/ldapaddgroup '%g'
        add user to group script = /usr/sbin/ldapaddusertogroup '%u' '%g'
        delete user script = /usr/sbin/ldapdeleteuser '%u'
        delete group script = /usr/sbin/ldapdeletegroup '%g'
        delete user from group script = /usr/sbin/ldapdeleteuserfromgroup '%u' '%g'
        set primary group script = /usr/sbin/ldapsetprimarygroup '%u' '%g'
        rename user script = /usr/sbin/ldaprenameuser '%uold' '%unew'

        # Global share settings
        admin users = @smb-domain-admins
        write list = @smb-domain-admins @ftpadmins

        browseable = Yes

        # We use POSIX ACLs to control real permissions
        writeable = Yes
        inherit acls = Yes
        inherit owner = Yes

[netlogon]
        path = /home/ftp/netlogon
        browseable = No

[pub]
        path = /home/ftp/pub

[shared]
        path = /home/ftp/shared

[private]
        path = /home/ftp/private/%u
        root preexec = /etc/samba/scripts/create-private-dir %u

[private-all]
        path = /home/ftp/private
        valid users = @ftpadmins

[1c-databases]
        path = /home/ftp/1c-databases
        valid users = @smb-1c-users
        csc policy = disable

Для ускорения работы можно вынести базы 1С на отдельный раздел с какой-нибудь быстрой ФС (типа ext4) и монтировать с опцией noatime. Ещё можно покрутить настройки TCP/IP-стека. У меня после добавления вот этого в sysctl.conf:

net.core.rmem_default = 1048576
net.core.rmem_max = 1048576
net.core.wmem_default = 1048576
net.core.wmem_max = 1048576
kernel.shmmax = 167772160

купить ethersoft wine
у них как раз таки патчи на сетевые блокировки для 1С

всё дело в оплоках

Кусок smb.conf для 1с-ной шары:

[1C-bases]
comment = Our 1C tank-a-drom
path = /home/1С
public = no
valid users = lu mari dina
writeable = yes
printable = no
create mask = 0770
browseable = yes
share modes = yes

oplocks = no

level2 oplocks = no

blocking locks = no

locking = yes

strict locking = no

force create mode = 0770
force directory mode = 0770


Необходимые установки выделены '>'

Работает уже лет пять под любыми версиями самбы.

Текущих версий две:3.0.4 и 3.2.5

Дистриб: Слака

Во многих рекомендациях по настройке 1с-ной шары рекомендуют эти опции не трогать из-за того, что скорость сетевых файловых операций снизится.

Однако этого не произошло и быстродействие именно 1С:Бухгалтерии даже превышало виндовозные.

>oplocks = no
>level2 oplocks = no
>blocking locks = no
>locking = yes
>strict locking = no

Сколько одновременных клиентов работают с базой при таких настройках?

>oplocks = no
>level2 oplocks = no
>blocking locks = no
>locking = yes
>strict locking = no

как ни странно, но при таких настройках у меня юзвери 1с не получали сообщение о том, что кто-то уже юзает базу и в один и тот же документ писали разом несколько человек.

При нижеследующей настройке - 2й год полет отличный (3 тьфу!).

сервер с базами 1с член домена DOM на Win 2003.

Дистр - слака 12.0, самба 3.2.15

вот конфиг:

[global]
interfaces = eth0 lo
hosts allow = 192.168.0. 127.
netbios name = dom-1c
workgroup = dom
password server = 192.168.0.1
server string = 1c bases
security = ADS
realm = DOM
#passdb backend = tdbsam
allow trusted domains = yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
os level = 1
preferred master = No
local master = No
domain master = No
dns proxy = No
ldap ssl = no
strict locking = No
time server = no
auth methods = winbind
encrypt passwords = yes
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
log file = /var/log/samba/log.%m
max log size = 1024
log level = 1
display charset = koi8-r
unix charset = koi8-r
dos charset = cp866
nt acl support = yes
printcap name = /etc/printcap
max xmit = 65535
dead time = 15
use sendfile = no
max open files = 65535
kernel oplocks = yes

[1c-buh]
  comment = 1c for Buhgalteriya
  path = /1c/buh
  admin users = @"DOM\администраторы домена"
  read only = no
  create mask = 1775
  directory mask = 1775
  printable = no
  available = yes
  map acl inherit = yes
  inherit owner = no
  inherit acls = no
  inherit permissions = no
  acl check permissions = true
  acl map full control = true
  blocking locks = yes
  level2 oplocks = yes
  locking = yes
  oplocks = yes
  strict locking = no
  posix locking = yes
  browseable = yes
  share modes = yes

о захвате блоков

blocking locks (S)
This parameter controls the behavior of smbd(8) when given a request by a client to obtain a byte range lock on a region of an open file, and the request has a time limit associated with it.
If this parameter is set and the lock range requested cannot be immediately satisfied, samba will internally
__queue the lock request__, and periodically attempt to obtain the lock until the timeout period expires.
->>>>> If this parameter is set to no, then samba will behave as previous versions of Samba would and will fail the lock request immediately if the lock range cannot be obtained.
Default: blocking locks = yes

->>>>> В случае сетевой файловой БД 1С 7.7 почему-то не хочет ждать освобождения блока, а вылетает аварийно по пути похерив работу всем остальным.
Поэтому выставив этот параметр в NO вынуждаем 1с тут же вывести на экран сообщение о невозможности открыть именно этот документ.
Через некоторое время сам оператор может повторять свои попытки. При этом у остальных работа не прекращается из-за краха 1С у этого оператора.

ЗЫ: Этот набор параметров таскаю уже давно _ничего_не_меняя_ начиная с версий самбы 2.0.с_чем_то.

об оппортунизме замков ;)

---->>>> oplocks (S)
This boolean option tells smbd whether to issue oplocks (opportunistic locks) to file open requests on this share. The oplock code can dramatically (approx. 30% or more) improve the speed of access to files on Samba servers. It allows the clients to aggressively cache files locally and you may want to disable this option for unreliable network environments (it is turned on by default in Windows NT Servers). For more information see the file Speed.txt in the Samba docs/ directory.
Oplocks may be selectively turned off on certain files with a share. See the veto oplock files parameter. On some systems oplocks are recognized by the underlying operating system. This allows data synchronization between all access to oplocked files, whether it be via Samba or NFS or a local UNIX process. See the kernel oplocks parameter for details.
Default: oplocks = yes
---->>>> Oplocks are the way that SMB clients get permission from a server to locally cache file operations. If a server grants an oplock opportunistic lock) then the client is free to assume that it is the only one accessing the file and it will aggressively cache file data. With some oplock types the client may even cache file open/close operations. This can give enormous performance benefits.

---->>>>>level2 oplocks (S)
This parameter controls whether Samba supports level2 read-only) oplocks on a share. Level2, or read-only oplocks allow Windows NT clients that have an oplock on a file to downgrade from a read-write oplock to a read-only oplock once a second client opens the file (instead of releasing all oplocks on a second open, as in traditional, exclusive oplocks). This allows all openers of the file that support level2 oplocks to cache the file for read-ahead only (ie. they may not cache writes or lock requests) and increases performance for many accesses of files that are not commonly written (such as application .EXE files).
!!!!---->>>> Once one of the clients which have a read-only oplock writes to the file all clients are notified (no reply is needed or waited for) and told to break their oplocks to «none» and delete any read-ahead caches.

----->>>>> Скорость сетевых файловых операций может и вырастет, однако без них и показатели реакции системы (то есть работы с 1с документами операторов на местах) даже превышали аналогичные показатели оффтопиковых серверов.

НО !!!---->>>> клиенты при разрешённых level2 oplocks могут внезапно получить команду очистить локальный буфер сетевого файла. Может быть здесь 1с и спотыкается.

о качестве полётов

>как ни странно, но при таких настройках у меня юзвери 1с не получали >сообщение о том, что кто-то уже юзает базу и в один и тот же документ >писали разом несколько человек.

При нижеследующей настройке - 2й год полет отличный (3 тьфу!).

Я очень рад!
Я не стал доподлинно вспоминать с какого года я ставлю клиентам такие настройки, ну, пусть 10. Когда начались версии 2.0.с_чем_то?
При всех других вариантах 1с 7.7 вылетала и --- скандал.
Все происходило из-за блокировок файлов Баз Данных.
Если учесть, что 1с 7.7 это огромная куча файлов и из них (не знаю сколько соврать) много должны быть заблокированы может возникнуть такой наворот с оппортунизмом замков ;) при работе даже двух копий 1с7.7 , что она вылетит круша БД.

о количестве клиентов

>Сколько одновременных клиентов работают с базой при таких настройках?

10-15.
И ещё бывали огромные БД 1с 7.7.

Vladan8888 сказал только не говорите про тормоза из-за сети.
И такое было.
Всего 5 машин, а работать не могут.
Пришлось их каждую к отдельному интерфейсу подключать.
Каждый из них умудрялись загрузить 100 мб под завязку.
А когда загрузили, пришлось менять весь комп, не хватало памяти и мощности процессора.
Лучше не рисковать, и не вешать в одном сегменте сети больше 5 машин с 1с 7.7 файловой БД. И больше никого.
Если в сегменте десяток компов и Вы включаете две машины с 1с 7.7, не тормозить для 1с 7.7 --- это будет чудо.
Причем речь уже и не о самбе.
При серьёзной работе с сочной БД 1с 7.7 20-40 машин, только RDP спасает, а файловая шара на оффтопике --- нет.

Ещё надо посмотреть характер работы:
ввод первичных документов? - это конечно заблокирует базу но кратковременно и трафик не повысит. Добавление записи в хвост никому особо не мешает.
получение отчётов? - это повысит трафик и может помешать редактированию существующих записей.

> Все происходило из-за блокировок файлов Баз Данных.

Если учесть, что 1с 7.7 это огромная куча файлов и из них (не знаю сколько соврать) много должны быть заблокированы может возникнуть такой наворот с оппортунизмом замков ;) при работе даже двух копий 1с7.7 , что она вылетит круша БД.

Честно, не очень понимаю, что тут плохого когда файл, будучи в использовании, заблокирован для других (пусть будет куча файлов - если они в данный момент юзаются)?
я ссылался на сюды когда правил свой конфиг:
http://smb-conf.ru/blocking-locks-s.html
http://smb-conf.ru/level2-oplocks-s.html
http://smb-conf.ru/locking-s.html
http://smb-conf.ru/oplocks-s.html
http://smb-conf.ru/strict-locking-s.html

Будьте осторожными при отключении блокировок как глобально так и для специфических сервисов, т.к. недостаток блокировок может привести к порче данных.

Это цитата от туда же.

И я честно хочу знать - может я не верно настроил конфиг?
и надо ждать сюрпризов?

и, наверное, все таки лучше изменю два параметра:
strict locking = auto
blocking locks = no

спасение в блокировках

>что тут плохого когда файл, будучи в использовании, заблокирован для других (пусть будет куча файлов - если они в данный момент юзаются)?

Это очень хорошо!
Всё дело в разной строгости разных типов блокировки.
Оплоки (в том числе и второго уровня) определяют можно ли файл забирать к себе и работать с ним локально, пока никто его не юзает.
blocking locks --- это когда разрешают работать разным процессам с одним и тем же файлом, но с разными, непересекающимися его кусками.

locking --- это когда вообще говорится не подходить даже к файлу, если с ним кто-то работает. Если эта опция сброшена, то на все запросы, отвечает сервер «можно!».

strict locking --- похожа, но работает в зависимости от оплоков.

Сейчас я смутно вспоминаю, что своим набором опций я пытался выключить всё что касается оплоков, попыток локальных станций утащить к себе кусок файла и с ним там работать.
То есть ужесточить-упростить сетевые файловые операции.
Работаешь? ---- заблокируй.
Отработал? ---- отпусти.
Без всяких там «А можно я домой возьму посмотреть?».
Или «Можно мы одну книжку вместе почитаем?»
В такой ситуации бывает у оператора выскакивает сообщение о том что сетевая операция не может быть выполнена. Понажимают пару-тройку раз и она проходит.

Скорость обработок не возросла, зато перестала 1С вылетать на полном ходу.

ЗЫ: Если работает Ваш набор опций, я очень рад.
Никому не пожелаю нервотрёпки с 1с 7.7 и самбой.
Но указанный мной набор испытан уже на 10 клиентах точно в течении достаточно долгого времени.
Пусть тот, кто сейчас мучается пробует все подсказанные варианты.
Главное, чтоб работало.

Всем откликнувшимся огромное спасибо, но ситуация пока что практически та же что и была(. Опишу свои последние мытарства. В силу того, что на работу я езжу где-то раз в неделю дня на два, собрал я сначала дома небольшой полигон из 3-х компов для экспериментов: одна машина на Ubuntu 9.10 с samba из ихних репов(3.4 кажись) и две на XP pro с сетевой 1с. Настраивал самбу так: добавил два тестовых польз-ля в линуху, добавил для них основную группу smbusers, добавил этих же польз-лей в самбу, в smb.conf прописал всё по минимуму - раб. группу, netbios name, security = user, расшарил папку DATA с небольшой тестовой базой(writable = yes, browsable = yes, valid users = @smbusers). И видно чего-то забыл, потому как одновременно к базе может обратиться только один польз-ль. Выражается это в следующем: один юзер сидит в базе, всё в поряде, второй юзер с другого компа открывает 1с, выбирает базу, жмёт ок, чтобы стало быть подключиться, появляется сплэш 1ски, на котором внизу написано «инициализация», висит секунды 2 и вместе с этой инициализацией уходит в небытие, т.е. просто исчезает, ничего не говоря. С этим приколом я не разобрался, поэтому в порядке эксперимента дописал к шаре «force user = test1», то бишь принудительно всех, кто к шаре обращается считать польз-лем test1 и от его имени открывать базу. Теперь оба пользователя заходят и всё бы хорошо, но старая проблема никуда не делась: как только подключается хотя бы 2 польз-ля, начинаются ничем не оправданные тормоза(захожу в базу, жму контрагенты, там у меня обычный список арендаторов, грузится с задержкой, прокрутка в нём работает со зверской задержкой, любые действия в базе оставляют ощущение, что одновременно с 1с на компе запущен какой-нибудь Crysis, идёт архивация с максимальным сжатием, и запущен калькулятор, уже минуты с 3 считающий факториал из 1000000000000. И пусть я немного преувеличиваю, но ведь для двух клиентов производительности файлового сервера должно хватать. Не платить же за терминалку(пусть даже и за wine etersoft) для двух-трёх клиентов одновременно работающих с базой(на нашем предприятии большего не нужно). Ещё один момент: я решил и на своём полигоне удостовериться, что производительности сети и желза хватает для моих нужд и что работа с 1с без тормозов по сети возможна, ну и кинул базы на XP и ооочень удивился, когда обнаружил, что при работе 2-х клиентов опять же тормоза, Но только у одного клиента. Ещё больше запутался. На работе при таком раскладе летали оба. Вернулся к экспериментам с самбой и, что интересно идентичное поведение с виндой начал наблюдать если добавлял fake oplocks = yes (это всё ещё с включённым force user). Экспериментировал и с veto oplocks(тормоза только усилились) и с csc policy(без эффекта). Попробовал кстати ASPLinux 14 Cobalt(его пока и оставил), предположив, что их сборка самбы должна быть заточена под работу с 1с, но ситуация получилась до боли знакомая)). Интересно всё-таки почему без force user не могу на базу заходить? Может, если каждый юзер будет от своего имени к базе обращаться, ситуация изменится? Может подскажет кто, куда копать. Энтузиазма пока ещё хватает, только подзаплутал я в этих самбовских дебрях). Буду долбить дальше, жду советов, только не забывайте писать кто какие версии самбы и дистрибы пользовал, может быть тоже важно, хотя бы для статистики.

трафик сети

Попробуй посмотреть трафик в сети, потому что ситуация какая-то фантастическая.
Значит надо начинать с начала.
В винде есть штатные утилиты графической демонстрации загрузки процессора, памяти, сети.
Посмотри что делается с сетью при подключении второго клиента.
Если трафик подскакивает до 70% от пропускной способности сети, то надо копать дальше.
Если трафик больше 70% --- надо чесать репу, потому что в езернет-сетях после этого работа практически прекращается, а начинается переповторение смятых пакетов.

Если с сетью всё в порядке --- ужесточи максимально правила доступа к разделяемым файлам.
То есть убери все свистульки типа оплоков.
Такие свистульки могут приводить к кленчам и постоянным сбросом и чтением локальных буферов и тд и тп.
Опции которые я приводил --- проверь.
Причём их с головой достаточно, больше и не надо.
С оплоками для 1С лучше не играться. По крайней мере сейчас.
Когда всё заработает, тогда и поэкспериментируешь.

вот такой же вопрос 6-летней давности

http://www.linux.org.ru/forum/admin/481174#comment-487407

Эту тему я видел.Там же вроде терминалка, судя по заглавию темы. У меня файловый сервер.

Посмотрел по вашему совету на загрузку сети через диспетчер задача: пик нагрузки при открытии базы примерно 15% (длится где-то секунды 3-4), далее нагрузка не подымается выше 2-3%. Да и я ж специально до этого создавал две одинаковые базы 1с в расшаренной папке, после чего одним клиентом в монопольном режиме осуществлял доступ к одной базе, вторым клиентом - к другой базе, в результате чего оба клиента летали, т.е. моей сети хватает с головой. А вот насчёт прав доступа к шарам - мне после последних экспериментов кажется, что тут собака явно могла порыться. Потому как не далее как вчера вечером, после того как я оставил на форуме очередное сообщение, у меня таки всё заработало... Заработало после того, как я добавил в smb.conf 2 опции: «blocking locks = no» и «csc policy = disable» (плюс у меня уже стояло force user = test1)... Заработало, но не надолго)). Оставив всё как есть и решив сделать перерыв, я на след. день начал вычислять, какая из двух опций заставила 1с нормально работать: сначала убрал одну, оставив другую и наоборот, результат - возврат к тормозам. Сделав логичный вывод, что нужны обе опции, я заменил smb.conf на рабочий(предварительно сохранённый)конфиг... и нифига)). В общем, чтоб долго не расписывать, скажу, что в ходе разбора полётов вспомнил, что переиндексировал базы(в ходе чего 1с заменяет индексные файлы с расширениями cdx в директории базы) - это раз. Обнаружил в выводе smbstatus, что эти вновь созданные индексные файлы имеют отличные блокировки от остальных файлов(EXCLUSIVE + BATCH) - это два. Это по идее связано с тем, что у меня не прописаны маски для создаваемых файлов в базе(т.е. владельцем cdx файлов становился пользователь, кот. проводил переиндексацию - мой force user test1). Повторно поменяв права на шару (chmod -vR 777 /media/DATA/SSTDB/), дав право владения группе smbusers (chgrp -vR smbusers /media/DATA/SSTDB/) и проверив работу 1с, выяснил, что вернуться к достигнутым ранее результатам не удалось(. А вот вспомнить сколько раз и от чьего имени я базы переиндексировал до того, как у меня всё заработало - вот хоть убейте не помню)). В общем, результаты есть, копаю дальше, только теперь буду учитывать, что на результат влияют не только блокировки.

Народ, подскажите настройки прав доступа на базы для нормальной работы 1с, чтобы отмести вариант, что там у меня не всё как надо: кто должен быть владельцем, какие должны быть права на чтение, запись. Где-то я читал, что владельцем базы 1с нужно назначать всю группу пользователей самбы, которые работают с базой (если не так поправьте). И ещё может кто скажет что на выводе smbstatus должно быть? Я заметил, что у меня в монопольном режиме(когда всё быстро работает) oplocks: NONE и deny mode: DENY ALL стоит. Видимо задача стоит в том, чтобы эти же показатели были и при параллельной работе юзеров?

да или нет?

Дорогой брат по бывшему несчастью, Vladan8888!

Обрати внимание на тот кусок smb.conf, который я привёл(на весь кусок).
Попробуй его и скажи результат.
С сеткой разобрались --- дело не в ней.
Теперь ты пишешь про грабли, которые уже пройдены именно в этом способе настройки: не ставишь force create mode.
Скажи мне тогда, дорогой брат, зачем ты спрашиваешь совета, если не пробуешь подсказки.
Я не знаю что такое csc policy, и теперь даже лень курить man, потому что в моём варианте конфигурации сразу было написано, что blocking locks=no, а ты говоришь что оказывается вот так теперь надо ставить.
Результат у меня есть и я покурю man на твою тему.
Но для этого нужен чёткий ответ: вот так сделал --- результат такой, куда копать дальше.
А так мы тут будем до зимы дрова рубить.

ЗЫ: В приведённой мной ссылке затрагивались все проблемы и твоя тоже, а не только терминальный доступ к виндовозу при работе с 1С.

Дык, ты же выделил

oplocks = no

level2 oplocks = no

blocking locks = no

locking = yes

strict locking = no

как необходимые, я и не принял во внимание force моды. В общем, исправил ошибку - проверил: если блокировки конфигурирую, как в твоём примере - тормоза даже, если один клиент заходит), но! зато теперь я могу заходить с двух клиентов, не используя параметр force user. Попробую-ка я ещё повертеть параметры. Скоро отпишусь.

notify:inotify = false