Тест простой: Нахожусь в локальном каталоге Есть смонтированный ресурс (//host01.eterhost.spb.ru/torrent /net/torrent cifs file_mode=0664,uid=lav,gid=users,password='') в /net/torrent каталог /net/torrent/Video/1 существует выполняю команду (под пользователем) $ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 && cp -a dtest /net/torrent/Video/1 создаётся только первый каталог иерархии иногда срабатывает более простой тест: находясь в смонтированном ресурсе выполняем mkdir -p 3/4 создаётся только каталог 3.
(In reply to comment #0) > Тест простой: Если это верно: > Нахожусь в локальном каталоге То причем здесь этот ресурс: > Есть смонтированный ресурс > (//host01.eterhost.spb.ru/torrent /net/torrent cifs > file_mode=0664,uid=lav,gid=users,password='') в /net/torrent Может вы все-таки находитесь в шаре? > каталог /net/torrent/Video/1 существует > выполняю команду (под пользователем) > $ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 && cp -a > dtest /net/torrent/Video/1 > > создаётся только первый каталог иерархии
(In reply to comment #1) > (In reply to comment #0) > > Тест простой: > > Если это верно: > > Нахожусь в локальном каталоге > > То причем здесь этот ресурс: Читайте до конца > > Есть смонтированный ресурс > > (//host01.eterhost.spb.ru/torrent /net/torrent cifs > > file_mode=0664,uid=lav,gid=users,password='') в /net/torrent > > Может вы все-таки находитесь в шаре? Читайте до конца > > > каталог /net/torrent/Video/1 существует > > выполняю команду (под пользователем) > > $ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 && cp -a > > dtest /net/torrent/Video/1 > > ключевое действие вот это cp -a dtest /net/torrent/Video/1 именно оно работает с CIFS, если Вы не заметили > > создаётся только первый каталог иерархии все что "до" создаёт иерархию каталогов. про локальный каталог акцентировано потому, что создаётся иерархия на локальной ФС, чтоб не было сомнений, что каталоги действительно создаются и мы копируем существующие объекты. PS: Вы действительно думаете, что я создал багу просто так?
> все что "до" создаёт иерархию каталогов. про > локальный каталог акцентировано потому, > что создаётся иерархия на локальной ФС, > чтоб не было сомнений, что каталоги > действительно создаются и мы копируем > существующие объекты. > > PS: Вы действительно думаете, что я создал > багу просто так? Не я так не думаю, просто не заметил, что последняя папка на шаре находится. Захотел уточнить. И не создается вообще? Как такой баг может оставаться незамеченным... Куча людей копирует иерархии файлов и не замечает этого. И у нас в офисе это пока не воспроизвелось.
Смонтировал шару: cifsmount //valhalla/public ~/sha -o file_mode=0664,uid=kipruss,gid=kipruss,password='' выполнил создание каталогов и файла и копирование. Не все права передались. [kipruss@valhalla ~]$ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 && cp -a dtest ~/sha/test1 cp: установка прав доступа для `/home/kipruss/sha/test1/dtest/dtest1/dtest2/ftest1': Отказано в доступе cp: установка прав доступа для `/home/kipruss/sha/test1/dtest/dtest1/dtest2': Отказано в доступе cp: установка прав доступа для `/home/kipruss/sha/test1/dtest/dtest1': Отказано в доступе cp: установка прав доступа для `/home/kipruss/sha/test1/dtest': Отказано в доступе Проверяю: [kipruss@valhalla ~]$ find ~/sha/test1 /home/kipruss/sha/test1 /home/kipruss/sha/test1/dtest /home/kipruss/sha/test1/dtest/dtest1 /home/kipruss/sha/test1/dtest/dtest1/dtest2 /home/kipruss/sha/test1/dtest/dtest1/dtest2/ftest1 Не воспроизвел. Возможно, зависит от настроек самбы.
Created attachment 1018 [details] testparm -v (In reply to comment #3) > > все что "до" создаёт иерархию каталогов. про > > локальный каталог акцентировано потому, > > что создаётся иерархия на локальной ФС, > > чтоб не было сомнений, что каталоги > > действительно создаются и мы копируем > > существующие объекты. > > > > PS: Вы действительно думаете, что я создал > > багу просто так? > Не я так не думаю, просто не заметил, что > последняя папка на шаре находится. Захотел > уточнить. сори, если ответил излишне резко-) > > И не создается вообще? Как такой баг может > оставаться незамеченным... Куча людей > копирует иерархии файлов и не замечает > этого. И у нас в офисе это пока не > воспроизвелось. > создаётся первая папка. если копировать через mc, например, такой проблемы нет. могу показать на любом компе из нашей сети. вывод testparm -v во вложении
(In reply to comment #0) > выполняем mkdir -p 3/4 > создаётся только каталог 3. > mkdir -p 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20 [kipruss@valhalla test1]$ find 1 1 [кусь] 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20
(In reply to comment #4) > Смонтировал шару: > > cifsmount //valhalla/public ~/sha -o > file_mode=0664,uid=kipruss,gid=kipruss,password='' > > выполнил создание каталогов и файла и > копирование. Не все права передались. Кстати, есть объяснение тому, что было отказано в изменении режима доступа?
(In reply to comment #4) > Смонтировал шару: > > cifsmount //valhalla/public ~/sha -o > file_mode=0664,uid=kipruss,gid=kipruss,password='' ... > Не воспроизвел. Возможно, зависит от > настроек самбы. > возможно влияет пользователь. под root такой проблемы не возникает. я же выполнял все от пользователя boris при параметрах монтирования file_mode=0664,uid=lav,gid=users,password='' пользователь boris состоит в группе users
Created attachment 1020 [details] valhalla_samba (In reply to comment #5) > вывод testparm -v во вложении > прикрепляю свой, почти дефолтный.
(In reply to comment #8) > (In reply to comment #4) > > Смонтировал шару: > > > > cifsmount //valhalla/public ~/sha -o > > file_mode=0664,uid=kipruss,gid=kipruss,password='' > ... > > Не воспроизвел. Возможно, зависит от > > настроек самбы. > > > > возможно влияет пользователь. под root такой > проблемы не возникает. я же выполнял все от > пользователя boris при параметрах > монтирования file_mode=0664,uid=lav,gid=users,password='' > пользователь boris состоит в группе users > Я намеренно скопировал данные параметры монтирования. Собственно я - kipruss:kipruss Права у каталогов получились - 700, у файла внутри - 600
(In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #4) > > > Смонтировал шару: > > > > > > cifsmount //valhalla/public ~/sha -o > > > file_mode=0664,uid=kipruss,gid=kipruss,password='' > > ... > > > Не воспроизвел. Возможно, зависит от > > > настроек самбы. > > > > > > > возможно влияет пользователь. под root такой > > проблемы не возникает. я же выполнял все от > > пользователя boris при параметрах > > монтирования file_mode=0664,uid=lav,gid=users,password='' > > пользователь boris состоит в группе users > > > > Я намеренно скопировал данные параметры > монтирования. Собственно я - kipruss:kipruss > > Права у каталогов получились - 700, у файла > внутри - 600 > о! почему? почему не 664 как было указано? если создать файл он ведь создастся с правильными правами (664)
mv 1 ~/sha/test1 тоже сбрасывает права в 700. Скорее всего это от настроек шары зависит.
(In reply to comment #12) > mv 1 ~/sha/test1 > > тоже сбрасывает права в 700. Скорее всего это > от настроек шары зависит. > у меня mv не сбрасывает. pwd /net/torrent/Video/1 [boris@lav 1]$ > 1 [boris@lav 1]$ ll итого 0 drwxrwxr-x 2 lav users 0 Янв 14 2009 ./ -rw-rw-r-- 1 lav users 0 Янв 14 2009 1 drwxrwxrwx 9 lav users 0 Янв 14 13:46 ../ [boris@lav 1]$ mv 1 2 [boris@lav 1]$ ll итого 0 drwxrwxr-x 2 lav users 0 Янв 14 2009 ./ -rw-rw-r-- 1 lav users 0 Янв 14 2009 2 drwxrwxrwx 9 lav users 0 Янв 14 13:46 ../
(In reply to comment #13) > (In reply to comment #12) > > mv 1 ~/sha/test1 > > > > тоже сбрасывает права в 700. Скорее всего это > > от настроек шары зависит. > > > > у меня mv не сбрасывает. > > pwd > /net/torrent/Video/1 > [boris@lav 1]$ > 1 > [boris@lav 1]$ ll > итого 0 > drwxrwxr-x 2 lav users 0 Янв 14 2009 ./ > -rw-rw-r-- 1 lav users 0 Янв 14 2009 1 > drwxrwxrwx 9 lav users 0 Янв 14 13:46 ../ > [boris@lav 1]$ mv 1 2 > [boris@lav 1]$ ll > итого 0 > drwxrwxr-x 2 lav users 0 Янв 14 2009 ./ > -rw-rw-r-- 1 lav users 0 Янв 14 2009 2 > drwxrwxrwx 9 lav users 0 Янв 14 13:46 ../ > а. тест не тот. да. тоже самое, что и при копировании
это сути особо не меняет. я хотел обратить внимание, что когда почти одновременно создаётся много файлов/каталогов возникает проблема. [boris@lav 1]$ pwd /net/torrent/Video/1 Раз [boris@lav 1]$ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 mkdir: невозможно создать каталог `dtest/dtest1': Отказано в доступе Два [boris@lav 1]$ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 mkdir: невозможно создать каталог `dtest/dtest1/dtest2': Отказано в доступе Три [boris@lav 1]$ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 touch: невозможно выполнить touch для `dtest/dtest1/dtest2/ftest1': Отказано в доступе Четыре [boris@lav 1]$ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 наконец-то все создалось Как будто дело в правах, но они ж меняются волшебным образом! (reread inode или я не знаю что)
Created attachment 1021 [details] diff между нашими smb.conf Вот diff между нашими smb.conf я добавил парамеры create mask = 0775 directory mask = 0775 не помогло. Всмысле права сбрасываются на 700 также, как и раньше
Под обычным cifs права тоже сбрасываются
Проверьте, может быть ваша бага из первого сообщения под обычным cifs тоже есть?
(In reply to comment #18) > Проверьте, может быть ваша бага из первого > сообщения под обычным cifs тоже есть? > да. все тоже самое
(In reply to comment #17) > Под обычным cifs права тоже сбрасываются > А из-под Убунту на той же шаре права при перемещении каталога не сбрасываются.
(In reply to comment #20) > (In reply to comment #17) > > Под обычным cifs права тоже сбрасываются > > > > А из-под Убунту на той же шаре права при > перемещении каталога не сбрасываются. > А можно как-то понять, из-за чего это различие? Я бы баг в Альт повесил. Или Вы-)
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #17) > > > Под обычным cifs права тоже сбрасываются > > > > > > > А из-под Убунту на той же шаре права при > > перемещении каталога не сбрасываются. > > > > А можно как-то понять, из-за чего это > различие? Я бы баг в Альт повесил. Или Вы-) > Да я, вот, думаю... Можно и баг или в devel, если нет боязни, что пошлют курить ман, как это принято у нас. Наверное, лучше так и сделать, чем самим думать над это, наверное, не самой важной проблемой. Если вам не лень повесить баг, то я - только за (подпишите меня - kipruss@altlinux.org ). Если лень - сам повешу. :)
Поскольку понятно, что это не наша бага, возможно имеет смысл сформулировать test case и отправить разработчикам cifs? Зачем нам самим решать все баги. Наверное, стоит проверить на Fedora/SUSE, надеюсь, это не чисто альтовая бага.
(In reply to comment #23) > Поскольку понятно, что это не наша бага, > возможно имеет смысл сформулировать test case > и отправить разработчикам cifs? Зачем нам > самим решать все баги. > Наверное, стоит проверить на Fedora/SUSE, > надеюсь, это не чисто альтовая бага. > (все примеры - в моем случае) Тесткейс1: 1. Примонтировать шару: sudo mount -t cifs //192.168.1.7/public ~/ttt -o noperm Почему так - без лишних параметров, но чтоб права были на копирование (noperm это дает) 2. Создать на локально некий каталог (обычно его права в таком случае - 755) mkdir ~/aaa 3. Переместить каталог на смонтированную шару mv ~/aaa ~/ttt 4. Проверить права каталога ~/ttt Ожидаемый результат: 755 (так кажется) Результаты1: 4.1. На АЛЬТе хоть с cifs, хоть с etercifs - 700 [kipruss@heaven ttt]$ ls -dl aaa drwx------ 2 kipruss kipruss 0 Янв 16 02:16 aaa 4.2. На Кубунту на домашнем ноуте - 700 kipruss@kubuntu:~$ ls -dl ~/ttt/aaa drwx------ 2 500 500 0 2009-01-16 02:30 /home/kipruss/ttt/aaa 4.3. На Кубунте на работе помню, что было 755. Или у меня глюки или я не знаю почему так, потому что Кубунты одинаковые, шары тоже используются одни и те же, что дома - одна и та же, что в офисе - другая, но тоже одна и та же. Тесткейс2: 1. Локально создать несколько вложенных каталогов и файл mkdir -p 2/3/4 2. Скопировать их на шару cp -a 2 ~/ttt 3. Посмотреть на них [kipruss@heaven ttt]$ find ~/ttt/2 2 2/3 2/3/4 Ожидается, что все они скопируются (на права внимания тут не обращаем). У меня и на АЛЬТе и на Кубунте так и есть. Как может быть по-другому я не понимаю.
(In reply to comment #24) > 1. Локально создать несколько вложенных > каталогов и файл Файл забыл создать. Но, думаю, что это не важно.
(In reply to comment #24) > 1. Примонтировать шару: > sudo mount -t cifs //192.168.1.7/public ~/ttt -o noperm > Почему так - без лишних параметров, но чтоб > права были на копирование (noperm это дает) Я так понимаю, что бага ярко проявляется только под пользователем и без noperm. И я не понимаю, ты отрицаешь, что проблема есть? :)
(In reply to comment #26) > Я так понимаю, что бага ярко проявляется > только под пользователем и без noperm. > И я не понимаю, ты отрицаешь, что проблема > есть? :) > В http://bugs.etersoft.ru/show_bug.cgi?id=3239#c4 я под пользователеи м без noperm монтировал, но багу пе воспроизвел. То есть, я, конечно, не могу отрицать, что проблема есть, но сам воспроизвести не могу.
(In reply to comment #27) > (In reply to comment #26) > > Я так понимаю, что бага ярко проявляется > > только под пользователем и без noperm. > > И я не понимаю, ты отрицаешь, что проблема > > есть? :) > > > > В http://bugs.etersoft.ru/show_bug.cgi?id=3239#c4 я под > пользователеи м без noperm монтировал, но багу > пе воспроизвел. То есть, я, конечно, не могу > отрицать, что проблема есть, но сам > воспроизвести не могу. > Ну, не знаю... воcпроизводится это просто: 1) Не работает [sin@server ~]$ cifsmount //server/upload upload/ Password: [sin@server ~]$ mkdir -p dtest/dtest1/dtest2 && touch dtest/dtest1/dtest2/ftest1 [sin@server ~]$ ls dtest/dtest1/dtest2/ftest1 dtest/dtest1/dtest2/ftest1 [sin@server ~]$ cp -a dtest upload cp: невозможно создать каталог `upload/dtest/dtest1': Отказано в доступе cp: сохранение временной отметки `upload/dtest': Операция не позволена [sin@server ~]$ ls -ld upload/dtest/ drwx--S--- 2 nobody users 0 Янв 16 09:46 upload/dtest/ 2) Не работает [sin@server ~]$ cifsumount upload/ [sin@server ~]$ mv dtest/ dtest2 [sin@server ~]$ cifsmount //server/upload upload/ -o user=sin Password: [sin@server ~]$ cp -a dtest2 upload cp: невозможно создать каталог `upload/dtest2/dtest1': Отказано в доступе cp: сохранение временной отметки `upload/dtest2': Операция не позволена [sin@server ~]$ ls -ld upload/dtest2 drwx--S--- 2 sin sin 0 Янв 16 09:48 upload/dtest2 [sin@server ~]$ ls upload/dtest2 [sin@server ~]$ mkdir upload/dtest2/dfds 3) Работает!!! [sin@server ~]$ cifsumount upload/ [sin@server ~]$ mv dtest2/ dtest3 [sin@server ~]$ cifsmount //server/upload upload/ -o noperm Password: [sin@server ~]$ cp -a dtest3 upload cp: установка прав доступа для `upload/dtest3/dtest1/dtest2/ftest1': Отказано в доступе cp: не удалось сохранить владельца `upload/dtest3/dtest1/dtest2': Отказано в доступе cp: не удалось сохранить владельца `upload/dtest3/dtest1': Отказано в доступе cp: не удалось сохранить владельца `upload/dtest3': Отказано в доступе [sin@server ~]$ ls -ld upload/dtest3 drwx--S--- 3 sin sin 0 Янв 16 09:45 upload/dtest3 [sin@server ~]$ ls -ld upload/dtest3/dtest1/ drwx--S--- 3 sin sin 0 Янв 16 09:45 upload/dtest3/dtest1/ [sin@server ~]$ ls -ld upload/dtest3/dtest1/dtest2/ drwx--S--- 2 sin sin 0 Янв 16 09:45 upload/dtest3/dtest1/dtest2/ [sin@server ~]$ ls -l upload/dtest3/dtest1/dtest2/ftest1 -rw------- 1 sin sin 0 Янв 16 09:45 upload/dtest3/dtest1/dtest2/ftest1 4) Не работает [sin@server ~]$ cifsumount upload/ [sin@server ~]$ cifsmount //server/upload upload/ -o file_mode=0664,dir_mode=0755,uid=sin Password: [sin@server ~]$ mv dtest3/ dtest4 [sin@server ~]$ cp -a dtest4 upload cp: невозможно создать каталог `upload/dtest4/dtest1': Отказано в доступе cp: сохранение временной отметки `upload/dtest4': Операция не позволена 5) Не работает [sin@server ~]$ cifsumount upload/ [sin@server ~]$ cifsmount //server/upload upload/ -o file_mode=0664,uid=sin Password: [sin@server ~]$ mv dtest4/ dtest5 [sin@server ~]$ cp -a dtest5 upload cp: невозможно создать каталог `upload/dtest5/dtest1': Отказано в доступе cp: сохранение временной отметки `upload/dtest5': Операция не позволена 6) Не работает [sin@server ~]$ cifsumount upload/ [sin@server ~]$ cifsmount //server/upload upload/ -o file_mode=0664,uid=sin,gid=sin Password: [sin@server ~]$ mv dtest5/ dtest6 [sin@server ~]$ cp -a dtest6 upload cp: невозможно создать каталог `upload/dtest6/dtest1': Отказано в доступе cp: сохранение временной отметки `upload/dtest6': Операция не позволена Общие параметры сервера: [global] workgroup = ALTDOMAIN server string = Samba server on %h (v. %v) printcap name = cups load printers = yes printing = cups max log size = 50 guest account = nobody security = share encrypt passwords = yes socket options = TCP_NODELAY dns proxy = no. use sendfile = yes Параметры шары: [upload] comment = Upload file space path = /var/ftp/upload read only = no browseable = no force user = nobody force group = users public = yes guest ok = yes Мой вывод: Нужно везде, где есть несовпадение uid'ов использовать именно noperm. Это параметр честно означает проверять все права на сервере... Примочки вида "file_mode=0664,uid=sin,gid=sin" - это не одно и то же... Иначе мы всё время будет нарываться на то, что утилиты будут сами себя ограничивать, как это происходит с 'cp'. 2kipruss: параметры шары //valhalla/public: [public] comment = Share on Valhalla path = /home/kipruss/share public = yes browseable = yes writable = yes guest ok = yes force user = kipruss create mask = 0775 directory mask = 0775 Проверь всё то же самое для force user != kipruss тоже работает... Для шары: [upload] comment = Upload file space path = /var/ftp/upload read only = no browseable = no #force user = nobody force user = sin force group = users public = yes guest ok = yes У меня тоже всё работает: [sin@server ~]$ cifsmount //server/upload upload/ -o file_mode=0664,uid=sin,gid=sin Password: [sin@server ~]$ mv dtest7/ dtest8 [sin@server ~]$ cp -a dtest8 upload cp: установка прав доступа для `upload/dtest8/dtest1/dtest2/ftest1': Отказано в доступе cp: не удалось сохранить владельца `upload/dtest8/dtest1/dtest2': Отказано в доступе cp: не удалось сохранить владельца `upload/dtest8/dtest1': Отказано в доступе cp: не удалось сохранить владельца `upload/dtest8': Отказано в доступе А вот параметры шары: create mask = 0775 directory mask = 0775 здесь никакой роли не играют... Для шары: [upload] comment = Upload file space path = /var/ftp/upload read only = no browseable = no force user = nobody force group = users public = yes guest ok = yes create mask = 0775 directory mask = 0775 Имеем то же самое: [sin@server ~]$ cifsmount //server/upload upload/ -o file_mode=0664,uid=sin,gid=sin Password: [sin@server ~]$ mv dtest6/ dtest7 [sin@server ~]$ cp -a dtest7 upload cp: невозможно создать каталог `upload/dtest7/dtest1': Отказано в доступе cp: сохранение временной отметки `upload/dtest7': Операция не позволена Проблема исключительно на uid'ах... Предлагаю всем переползать на noperm.
Created attachment 1027 [details] лог strace [kipruss@valhalla ~]$ mkdir sha1 [kipruss@valhalla ~]$ cifsmount //server/upload ~/sha1 -o uid=kipruss [kipruss@valhalla ~]$ mkdir -p k1/k2/k3/k4 [kipruss@valhalla ~]$ touch k1/k2/k3/k4/f1 [kipruss@valhalla ~]$ cp -a k1 ~/sha1 cp: невозможно создать каталог `/home/kipruss/sha1/k1/k2': Отказано в доступе cp: сохранение временной отметки `/home/kipruss/sha1/k1': Операция не позволена [kipruss@valhalla ~]$ ls -ld ~/sha1/k1 drwx--S--- 2 kipruss kipruss 0 Янв 16 16:24 /home/kipruss/sha1/k1 [kipruss@valhalla ~]$ stat ~/sha1/k1/ File: `/home/kipruss/sha1/k1/' Size: 0 Blocks: 0 IO Block: 16384 Каталог Device: 15h/21d Inode: 57207 Links: 2 Access: (2700/drwx--S---) Uid: ( 500/ kipruss) Gid: ( 500/ kipruss) Access: 2009-01-16 16:24:55.000000000 +0300 Modify: 2009-01-16 16:24:30.000000000 +0300 Change: 2009-01-16 16:24:30.000000000 +0300 [kipruss@valhalla ~]$ mv k2 k8 [kipruss@valhalla ~]$ strace cp -a k8 ~/sha1 &> /tmp/3239.txt Файл прилагаю. Кстати, force user я не убирал.
(In reply to comment #29) > > Кстати, force user я не убирал. > Эта фраза - ошибочная.
(In reply to comment #28) ... > Проблема исключительно на uid'ах... Предлагаю > всем переползать на noperm. Я думаю что прежде надо выяснить, чем вызвана проблема. Мне так кажется, просто нашим невладением ситуацией. noperm не вполне подходит, ведь это вызовет необходимость создавать промежуточный локальный каталог, с помощью прав на который регулировать права доступа локального пользователя. Прошу привести пример, как будет осуществляться разграничения доступа при монтировании /home на терминальном сервере без noperm.
(In reply to comment #31) > Я думаю что прежде надо выяснить, чем > вызвана проблема. Мне так кажется, просто > нашим невладением ситуацией. > noperm не вполне подходит, ведь это вызовет > необходимость создавать промежуточный > локальный каталог, с помощью прав на > который регулировать права доступа > локального пользователя. > > Прошу привести пример, как будет > осуществляться разграничения доступа при > монтировании /home на терминальном сервере > без noperm. Что с noperm, что без noperm, с правами все будет одинакого. Разница в том, что если noperm не указан, то должно работать чуть быстрее, но будет глючить, если нет синхронизации по uid, или если мы монтируем шару от другого имени пользователя. Так что noperm можно применять почти всегда не задумываясь. И вообще странно, что такое поведение не используется по умолчанию. Если, конечно, я все правильно про него понимаю.
Действительно, для клиента Kubuntu то же самое. Соответственно, баг может быть: на cifs (общая бага) или на альтовой самбе или на любой самбе.
(In reply to comment #32) > (In reply to comment #31) > > Я думаю что прежде надо выяснить, чем > > вызвана проблема. Мне так кажется, просто > > нашим невладением ситуацией. > > noperm не вполне подходит, ведь это вызовет > > необходимость создавать промежуточный > > локальный каталог, с помощью прав на > > который регулировать права доступа > > локального пользователя. > > > > Прошу привести пример, как будет > > осуществляться разграничения доступа при > > монтировании /home на терминальном сервере > > без noperm. > Что с noperm, что без noperm, с правами все будет > одинакого. Я так думаю, что с noperm любой пользователь сможет читать любые файлы в /home. > > Разница в том, что если noperm не указан, то > должно работать чуть быстрее, но будет Почему чуть быстрее, я не понимаю. > глючить, если нет синхронизации по uid, или Глючить не должно в любом случае. Должно работать ожидаемо. Если есть глюки, их надо нанести на карту. > если мы монтируем шару от другого имени > пользователя. Тут наверное есть момент, который плохо понимаем, с пересечением uid на сервере/клиенте. Возможно его стоит подробнее объяснить в рассылке.
Проверил по случаю с довоенным ASPLinux 11.2 копирование кучи вложенных каталогов с локальной папки в шару, смонтированную с noperm. Права у папок были 755.
Создана страница на Вики для гипотез и удобного вывода результатов. Заполню скоро что есть. http://wiki.office.etersoft.ru/testing/cifs/ProblemMkdir
Пакет ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/noarch/RPMS.default/etercifs-4.2.0-alt1.noarch.rpm содержит патч, предложенный в письме http://lists.etersoft.ru/pipermail/devel/2009-February/001116.html для ядер с 25 по 28. Надо протестировать.
(In reply to comment #37) > Надо протестировать. > Протестировал. Работает.
