> Всяческие fat-ы и msfs-ы, [и cifs-ы, кажется] не имеют в своей
> структуре поддержки unix-оподобных ugo^rwx битов и uid+gid-идентификации. Драйверы "неродных"
> FS пытаются представить то, что имеют, так, как могут. В результате
> то, что мы видим, в таким образом смонтированной фс обычно некая
> "подстановка"/имитация, демонстрируемая драйвером ФС, а какие права на вновь сохданные
> "здесь" фс-объекты увидят пользователи оригтнальныъ реализаций "там" (на винде, на том
> конце smb:// протокола [да, я слышал краем уха про посикс-расширения, но
> не видел ни разу]) -- может быть непредсказуемо и неожидаемо.Само себе это понятно. Но в контексте вопроса, это означает, что права на папки лежащие внутри раздела с неродной ФС поменять не факт что удастся? А на саму папку, которая находится на родной ФС и к которой смонтирован раздел?
> Почитайте man-страницы драйвера, или даже соотв.команды mount.XXXXfs, той ФС на предмет
> опций [монтирования] umask=, user=, file_mode=, dir_mode= и пр. Имейте также в
> виду, что не все реализации различных ФС (драйверы ФС) поддерживают все
> такие опции или даже используют их оданаково. Возможно, придётся поперебирать варианты,
> пока оно "взлетит" с доп.опциями
> umask в шеде и umask= опция монтирования (если она вообще есть) -
> разные вещи. А можно поменять умолчание umask-опции монтирования? На 0000. Для меня это было гораздо более предсказуемым поведением ОС.
> Хотелось бы также услышать, чего же вы желаете добиться. Не "поменять права
> на ...", а в результате этого -- "дать доступ пользователю не-root-у
> к разделу на флэшке", например?
> ...ext3 тоже на флэшке, например? Так и есть, хочу дать права пользователям (minidlna и ..debian-transmission вроде)
|
