Bug 4292

1. Монтировать командой etermount, а также обычной строкой, без параметра noperm
2. Подтвердить, что поведение одинаково для Ubuntu и ALT Linux

etercifs 4.3.8
Если монтировать с параметром noperm, то сохраняется без проблем, если смонтировано без данного параметра, то ошибка сохранения нет прав у пользователя.

На ALTLinux и Ubuntu поведение одинаковое.

Как сообщается, проблема вызвана использованием параметра direct.
Нужно определиться с этим, и либо устранить зависимость, либо убрать необходимость в direct.

Перешли капитально на etercifs 4.2.8, используем параметры serverino,forcemand
Повалились баги:
Невозможно с шары прикрепить файлик - повисает почтовик. Проявляется в том случае, если путь содержит симлинк. Пример:
Шара /M/mati/lkk/^gmn/file.doc - в этом случае висим*
Шара /M/mati/lkk/file.doc - в этом случае работаем нормально
*)где ^gmn - симлинк на папочку M/noth/gmn на той-же шаре. M - точка монтирования шары. Всё остальное - уже на ней.

При снятии параметра forcemand баги исчезли.:)))

Также при наличии параметра forcemand в большом количестве повисает опеноффис, причём ошибка стохастична.

В этой баге представлено три проблемы:
1) Права доступа без использования параметра noperm (комментарий #2)
Это нормально, если не отслеживать соответствие uid'ов и gid'ов на разных хостах. 

Нужно добавить noperm в etermount, если хотим избавится от этой проблемы. Иначе проблема будет всплывать вновь и вновь... Понять суть этой проблемы не тривиально, для каждого нового пользователя. И даже опытные на ней спотыкаются...

2) "Как сообщается, проблема вызвана использованием параметра direct" (комментарий #3). Какая проблема имеется в виду? Где и кем она сообщается? Можно по подробнее? Лучше с интерпретацией и алгоритмом воспроизведения.

От себя я могу догадаться, что без использования noperm проблема с правами проявляется только с параметром direct. Вообще, странно получается. Но, при последовательном прочтении комментариев, другого вывода сделать не могу...

3) Зависания при использовании forcemand (комментарий #4). Видимо, суть проблемы всё-таки в этом, но о чём тогда были предыдущие комментарии?

С ходу, ответ могу дать простой. Не используйте forcemand для монтирования тех общих каталогов, с которыми будут работать обычные (не wine) приложения. Этот параметр монтирования включает поведение файловой системы, на которое нормальные приложения в Unix не рассчитывают.

В чём необходимость использования этого флага для общих каталогов не с базами 1С?

(In reply to comment #6)
> В этой баге представлено три проблемы:
> 1) Права доступа без использования
> параметра noperm (комментарий #2)
> Это нормально, если не отслеживать
> соответствие uid'ов и gid'ов на разных хостах. 
> 
> Нужно добавить noperm в etermount, если хотим
> избавится от этой проблемы. Иначе проблема
> будет всплывать вновь и вновь... Понять суть
> этой проблемы не тривиально, для каждого
> нового пользователя. И даже опытные на ней
> спотыкаются...

Мгм. Собственно лишь бы была возможность его отключать. Чтобы по прежнему можно было использовать "тонкую" настройку прав доступа на файлошарах.:))) 
И кстати говоря вопрос разрешений вполне актуален даже для каталогов с 1С.

P.S.: естественно, тут нужно понимание вопроса соответствия uid и gid локально/на сервере...:)
> 
> 2) "Как сообщается, проблема вызвана
> использованием параметра direct" (комментарий
> #3). Какая проблема имеется в виду? Где и кем
> она сообщается? Можно по подробнее? Лучше с
> интерпретацией и алгоритмом
> воспроизведения.
> 
> От себя я могу догадаться, что без
> использования noperm проблема с правами
> проявляется только с параметром direct.
> Вообще, странно получается. Но, при
> последовательном прочтении комментариев,
> другого вывода сделать не могу...
> 
> 3) Зависания при использовании forcemand
> (комментарий #4). Видимо, суть проблемы
> всё-таки в этом, но о чём тогда были
> предыдущие комментарии?
> 
> С ходу, ответ могу дать простой. Не
> используйте forcemand для монтирования тех
> общих каталогов, с которыми будут работать
> обычные (не wine) приложения. Этот параметр
> монтирования включает поведение файловой
> системы, на которое нормальные приложения
> в Unix не рассчитывают.
> 
> В чём необходимость использования этого
> флага для общих каталогов не с базами 1С?
> 
Да уже так сделали конечно. Пока никаких неприятностей ни с виндовой ни с никсовых машин не наблюдали.:))) Данный комментарий был повешен сугубо в информативном ключе.:)

(In reply to comment #6)
> В этой баге представлено три проблемы:
> 1) Права доступа без использования
> параметра noperm (комментарий #2)
> Это нормально, если не отслеживать
> соответствие uid'ов и gid'ов на разных хостах. 
> 
> Нужно добавить noperm в etermount, если хотим
> избавится от этой проблемы. Иначе проблема
У нас noperm в etermount и так добавлено. Возможно стоит настоятельно рекомендовать его использовать.

> С ходу, ответ могу дать простой. Не
> используйте forcemand для монтирования тех
> общих каталогов, с которыми будут работать
> обычные (не wine) приложения. Этот параметр
> монтирования включает поведение файловой
> системы, на которое нормальные приложения
> в Unix не рассчитывают.
А в чём причина использования этого параметра нами?

(In reply to comment #8)
> (In reply to comment #6)
> > В этой баге представлено три проблемы:
> > 1) Права доступа без использования
> > параметра noperm (комментарий #2)
> > Это нормально, если не отслеживать
> > соответствие uid'ов и gid'ов на разных хостах. 
> > 
> > Нужно добавить noperm в etermount, если хотим
> > избавится от этой проблемы. Иначе проблема
> У нас noperm в etermount и так добавлено. Возможно
> стоит настоятельно рекомендовать его
> использовать.
> 
> > С ходу, ответ могу дать простой. Не
> > используйте forcemand для монтирования тех
> > общих каталогов, с которыми будут работать
> > обычные (не wine) приложения. Этот параметр
> > монтирования включает поведение файловой
> > системы, на которое нормальные приложения
> > в Unix не рассчитывают.
> А в чём причина использования этого
> параметра нами?

Такие вопросы меня всегда сбивают с толку. Этот момент уже рассматривался и описан в документации:
http://www.etersoft.ru/content/view/56/156/#x52

Основная причина в том, что в протоколе CIFS существует единственный стандартный вызов для работы с блокировками: SMB_COM_LOCKING_ANDX, но во время монтирования с включёнными unix extensions, вместо него, в специальном методе CIFSSMBPosixLock, используется специальный запрос TRANS2_SET_FILE_INFORMATION, который работает только на Samba. Этот параметр включает использование исходного метода.

В общем для единообразия и совместимости используется этот параметр нами.

Учитывая последние проблемы с необходимостью отключения сброса блокировок после закрытия файла, при работе подключении общих каталогов с базами, вместо forcemand, следует использовать nounix.
Я так понял, что для wine >= 1.0.10 это критично.

А что с direct? В чём с ним проблема? То, что он требуется уже само по себе, конечно, проблема... Но в была ведь какая-то частная проблема. Если этой проблемы нет, то текущую багу можно закрывать... Я не вижу никаких проблем, которые нужно исправить, кроме концептуальных...

(In reply to comment #9)
> А что с direct? В чём с ним проблема? То, что он
> требуется уже само по себе, конечно,
> проблема... Но в была ведь какая-то частная
> проблема. Если этой проблемы нет, то
> текущую багу можно закрывать... Я не вижу
> никаких проблем, которые нужно исправить,
> кроме концептуальных...
> 

Так, ну я нашёл откуда растут ноги у этой проблемы:
http://bugs.etersoft.ru/show_bug.cgi?id=4290#c19

Ну так ведь нельзя, если не можете описать, делайте ссылку хотя бы на источник... А то оно у меня под носом лежит, а я у всех спрашиваю... Из содержимого комментариев этой баги, однозначных выводов о самой проблеме сделать нельзя. Нужно быть "в теме"... Знать про другие баги и не только...

В общем, проблему с direct не подтверждаю, ошибка действительно возникает, но при отсутствии флага noperm, когда, клиент, по сути, сам себе запрещает доступ из-за отсутствия соответствий между uid'ами и gid'ами на нём и на сервере.

> В общем, проблему с direct не подтверждаю,
> ошибка действительно возникает, но при
> отсутствии флага noperm, когда, клиент, по
> сути, сам себе запрещает доступ из-за
> отсутствия соответствий между uid'ами и
> gid'ами на нём и на сервере.

uid'ы и gid'ы на клиентах и серверах идентичны. Посему, судя по man mount'у, необходимости в параметре noperm нету. А права доступа _нужно_ использовать, поскольку есть люди, которые любят лезть куда не надо.

Оговорюсь, что всё описанное проверяется/работает на связке samba-cifs. В условиях Windows-cifs и samba-Windows не проверялось.

Повторюсь за Алексеем http://bugs.etersoft.ru/show_bug.cgi?id=4292#c7 , что у нас для разных шар (1C, файлохранилище) используются разные наборы параметров монтирования, что позволяет избегать баги. Но это не решает её.

Если появится ситуация, когда на одной шаре нужны будут и права пользователей(acl), и базы 1С, и работа с документами ООО, то проблема вновь всплывет.

(In reply to comment #11)
> Повторюсь за Алексеем
> http://bugs.etersoft.ru/show_bug.cgi?id=4292#c7 , что у нас для
> разных шар (1C, файлохранилище) используются
> разные наборы параметров монтирования, что
> позволяет избегать баги. Но это не решает
> её.
 
В текущем состоянии связки Samba-Cifs-Wine эта проблема не имеет решения. Для запуска Windows приложений на сетевых каталогах применяется механизм, изменяющий логику внутренней работы файловых блокировок.

> Если появится ситуация, когда на одной шаре
> нужны будут и права пользователей(acl), и
> базы 1С, и работа с документами ООО, то
> проблема вновь всплывет.
> 

В текущем состоянии такие ситуации не поддерживаются в полной мере, в силу технических ограничений. По сути, для совместной работы Windows-приложений в wine (например, 1С-бухгалтерия) поведение файловой системы требуется одно, а для совместной работы Linux (например, OpenOffice) - другое.

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

Действительно, проблема обнаруживается с direct и без noperm:

[sin@server ~]$ ls /home/sin/upload/sin/ -ld
drwxrwsrwx 2 sin users 0 Окт 15 19:05 /home/sin/upload/sin/
[sin@server ~]$ ls /home/sin/upload/sin/ -l
итого 0
-rw-r--r-- 1 nobody users 0 Окт 15 19:05 eee
[sin@server ~]$ touch /home/sin/upload/sin/eee2
touch: невозможно выполнить touch для `/home/sin/upload/sin/eee2': Отказано в доступе
[sin@server ~]$ ls /home/sin/upload/sin/ -l
итого 0
-rw-r--r-- 1 nobody users 0 Окт 15 19:05 eee
-rw-r--r-- 1 nobody users 0 Окт 15 19:06 eee2
[sin@server ~]$ touch /home/sin/upload/sin/eee3
touch: невозможно выполнить touch для `/home/sin/upload/sin/eee3': Отказано в доступе
[sin@server ~]$ ls /home/sin/upload/sin/ -l
итого 0
-rw-r--r-- 1 nobody users 0 Окт 15 19:05 eee
-rw-r--r-- 1 nobody users 0 Окт 15 19:06 eee2
-rw-r--r-- 1 nobody users 0 Окт 15 19:06 eee3

Патч, предложенный в баге 4370, решает и эту проблему.

Дополнительный тест по работе OpenOffice.org на CIFS:
- нужно открыть один и тот же документ с разных машин. Если OpenOffice запущен с поддержкой блокировок (SAL_ENABLE_FILE_LOCKING=1 в /etc/sysconfig/openoffice.org),
то второй пользователь сможет открыть документ только на чтение (заметив, что документ уже используется).

Вышеописанный тест проходит корректно и с патчем из 4370, и без него.

надо проверить на cifs 4.4.1
Виталик предлагает монтировать с разными опциями для вайн и для доков опенофис.

после теста - решаем что делать с багой

Сборка 4.1.1 не содержит исправления из баги 4370, которое решает проблему работы OpenOffice на каталогах, смонтированных с параметром direct.

(In reply to comment #18)
> Сборка 4.1.1 не содержит исправления из баги
> 4370, которое решает проблему работы OpenOffice на
> каталогах, смонтированных с параметром
> direct.
То есть это будет только в следующих сборках?
Я никак не могу понять, где можно узнать что же туда вошло.
Похоже Жене надо указывать номер решаемой баги (fix eterbug #такой-то)

* Tue Oct 27 09:00:00 2009 Evgeny Sinelnikov <sin@altlinux.ru> 4.4.0-alt1
- Fixed mandatory reading problems

* Tue Oct 27 09:00:00 2009 Evgeny Sinelnikov <sin@altlinux.ru> 4.3.9-alt2
- Update fixes for 2.6.31

* Wed Oct 14 10:00:00 2009 Evgeny Sinelnikov <sin@altlinux.ru> 4.3.9-alt1
- Fixed fd duplicate problem with locks
- Add sources for 2.6.31

etercifs 4.4.1-eter1ubuntu

MOUNT_OPTIONS=user=guest,pass=,rw,iocharset=utf8,noperm,forcemand,direct
Поведение:
Файл созданный в OO сохраняется без проблем
MOUNT_OPTIONS=user=guest,pass=,rw,iocharset=utf8,noperm,forcemand
Поведение:
Файл созданный в OO сохраняется без проблем
MOUNT_OPTIONS=user=guest,pass=,rw,iocharset=utf8,forcemand,direct
Поведение:
Ошибка при сохранении.

Тест на открытие одного файла проходит успешно во всех вариантах монтирования

В третьем случае без параметра noperm скорее всего проблема с правами, так как дополнительно не указаны ни uid, ни gid. Драйвер тут не причём.

На сколько я понимаю нас устараивает первый вариант монтирования из Комментарий #20.
Значит бага решена и можно закрывать

Цитата из моего же поста #11 http://bugs.etersoft.ru/show_bug.cgi?id=4292#c11
"А права доступа _нужно_ использовать"

Т.е. первый вариант НЕ подходит.
Бага НЕ решена, а найден способ её избежать! ..ценой функциональности!

В том же #20 третий вариант заканчивается ошибкой сохранения. Это так или уже исправлено?

(In reply to comment #23)
> В том же #20 третий вариант заканчивается
> ошибкой сохранения. Это так или уже
> исправлено?
> 
Нет, еще не исправлено, открываю для исправления.

Исследовал проблему.

На ooffice 3.1 используются блокировки, потому параметр forcemand использовать вообще нелья - он ломает логику работы (ведь ooffice думает, что блокировки advisory).

Без параметра forcemand потестировал, и всё работает хоть с direct, хоть без него!

Вывод: для работы с OpenOffice монтировать шару без параметра forcemand.

(In reply to comment #25)
> Без параметра forcemand потестировал, и всё
> работает хоть с direct, хоть без него!

Попробовал:
MOUNT_OPTIONS=user=guest,pass=,rw,iocharset=utf8,direct

Проблема с сохранением файла из OO проявляется.

Как проявляется?

etercifs-4.4.2-eter3
Fedora 12, X86_64

[piastry@keepcoding 2.6.31]$ uname -a
Linux keepcoding 2.6.31.9-174.fc12.x86_64 #1 SMP Mon Dec 21 05:33:33 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux

smb.conf:
[global]
        security = user
[public]
        comment = Public Stuff
        path = /home/piastry/share
        public = yes
        writable = yes
        printable = no

[piastry@keepcoding m]$ sudo mount -t cifs //127.0.0.1/public ~/m -ouser=test,passwd=,direct,rw,iocharset=utf8

[piastry@keepcoding m]$ ls -la test.odt
-rwxr--r--. 1 piastry piastry 7246 Янв 22 12:41 test.odt

Открываю через ooffice файл test.odt изменяю и сохраняю - всё работает. Так же удаётся создать файл test2.odt, сохранить, изменить, а потом снова сохранить!

(In reply to comment #27)
> Как проявляется?
> 
uname -a
Linux lin-test 2.6.31-18-generic #55-Ubuntu SMP Fri Jan 8 14:54:52 UTC 2010 x86_64 GNU/Linux

[share]
        comment = Public share
        path = /var/tmp/share
        public = yes
        writable = yes
        printable = no

MOUNT_OPTIONS=user=guest,pass=,rw,iocharset=utf8,direct

Создаю новый файл в OO, пытаюсь сохранить его на смонтированный ресурс и возникает ошибка ввода-вывода.

Так. Надо понять, в чём различие наших тестовых платформ. Что в [global] секции из smb.conf и какова версия etercifs? Есть ли права на запись в каталог после монтирования?

Так же интересно, что будет без параметра direct - на моей системе всё корректно!

Совместными усилиями выяснили что такое различное поведение вызвано тем что у меня Ubuntu, а Паши Fedora.

Оказывается дело не в дистрах. Дело в расположении шары: если сервер находится на том же компьютере, что и клиент, то всё нормально работает. Если же на разных, то возникают проблемы доступа.

(In reply to comment #31)
> Оказывается дело не в дистрах. Дело в
> расположении шары: если сервер находится
> на том же компьютере, что и клиент, то всё
> нормально работает. Если же на разных, то
> возникают проблемы доступа.
> 

У меня на Ubuntu сервер и клиент были одна и та же машина.

Исследовал проблему ещё дальше - проблема
локализовалась.

При работе с Ubuntu Karmic Koala возникают проблемы
на уровне прав. Проявляется это при:
1) работе с cifs драйвером на Ubuntu Karmic Koala и
шарой на другом компьютере (Fedora 12),
2) работе с cifs драйвером на другом
компьютере (Fedora 12, CentOS 5.4) и шарой на Ubuntu Karmic
Koala.

В тоже время если и драйвер cifs и шара
используется с одного компьютера под Ubuntu
Karmic Koala, то тоже всё нормально.

Вывод: В Ubuntu Karmic Koala есть какие-то отличия
(предположительно в работе с файловой
системой) от других.

toBaraka: Желательно бы ещё протестировать Ubuntu
более старых версий.

Проблема с правами была связана с несовпадениям uid'ов и gid'ов на сервере и клиенте - потому и не работал вариант без "noperm". Ubuntu или ещё какой-то дистр здесь действительно не причём.

При монтировании без "noperm" происходит две проверки прав:
1) на клиенте - права пользователя, от которого пытаемся выполнить действие,
2) на сервере - права пользователя, от которого монтируем (user параметр),
и необходимо, чтобы обе они прошли верно.

При монтировании с "noperm" мы опускаем первую проверку.

По баге: Open Office работает корректно на последнем etercifs-4.4.2-eter3 без использования параметров forcemand или nounix. Последние нарушают его логику работы, так как заставляют драйвер работать с mandatory блокировками.

Fixed.

(In reply to comment #17)
> надо проверить на cifs 4.4.1
> Виталик предлагает монтировать с разными
> опциями для вайн и для доков опенофис.

Собственно бага решена, думаю теперь ясно что нужно монтировать с разными параметрами и написать об этом где-то (http://bugs.etersoft.ru/show_bug.cgi?id=4887)