- Изменение прав на папку к которой смонтирован раздел, nrv, 12:44 , 18-Мрт-17 (1)
Изменил umask на 0000 в /etc/pam.d, перезагрузил, теперь не могу зайти по ssh: сразу после ввода пароля выходит приветствие и потом соединение закрывается. Очень весело
- Изменение прав на папку к которой смонтирован раздел, Andrey Mitrofanov, 16:06 , 18-Мрт-17 (2)
> Здравствуйте. > Просвятите, пожалуйста, насчет ситуации с изменением прав на папки. > Есть 2 папки, к которым примонтированы соотвествующие разделы диска, один NTFS, другой > ext3. Просто с помощью chown (chown -R :mygroupname /myfolder | chown > -R root:mygroupname /myfolder) группу папки сменить не удалось. Если отмонтировать раздел, Всяческие fat-ы и msfs-ы, [и cifs-ы, кажется] не имеют в своей структуре поддержки unix-оподобных ugo^rwx битов и uid+gid-идентификации. Драйверы "неродных" FS пытаются представить то, что имеют, так, как могут. В результате то, что мы видим, в таким образом смонтированной фс обычно некая "подстановка"/имитация, демонстрируемая драйвером ФС, а какие права на вновь сохданные "здесь" фс-объекты увидят пользователи оригтнальныъ реализаций "там" (на винде, на том конце smb:// протокола [да, я слышал краем уха про посикс-расширения, но не видел ни разу]) -- может быть непредсказуемо и неожидаемо. Почитайте man-страницы драйвера, или даже соотв.команды mount.XXXXfs, той ФС на предмет опций [монтирования] umask=, user=, file_mode=, dir_mode= и пр. Имейте также в виду, что не все реализации различных ФС (драйверы ФС) поддерживают все такие опции или даже используют их оданаково. Возможно, придётся поперебирать варианты, пока оно "взлетит" с доп.опциями. > то права меняются, но изменяются, если смонтировать обратно. Плюс еще читал > на каком-то форуме сообщение, что что-то там umask. То есть, из-за umask в шеде и umask= опция монтирования (если она вообще есть) - разные вещи. > политики назначения прав по умолчанию я не могу по-человечески поменять права. Хотелось бы также услышать, чего же вы желаете добиться. Не "поменять права на ...", а в результате этого -- "дать доступ пользователю не-root-у к разделу на флэшке", например? ...ext3 тоже на флэшке, например?
- Изменение прав на папку к которой смонтирован раздел, nrv, 16:52 , 18-Мрт-17 (3) –1
> Всяческие 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 вроде)
- Изменение прав на папку к которой смонтирован раздел, nrv, 22:16 , 20-Мрт-17 (4)
Спасибо. Отчасти получилось, но добавляются __x права. От параметра umask отказался, когда пробовал, он меняет права на какие-то другие. В конечном итоге всегда не те :(. А смену владельца и группы для NTFS вылечил явным указанием uid и gid в опциях монтирования. Для ext3 владелец и группа не меняются при монтировании с дефолтными параметрами.
- Изменение прав на папку к которой смонтирован раздел, Павел Самсонов, 12:27 , 22-Мрт-17 (5)
>[оверквотинг удален] >> структуре поддержки unix-оподобных ugo^rwx битов и uid+gid-идентификации. Драйверы "неродных" >> FS пытаются представить то, что имеют, так, как могут. В результате >> то, что мы видим, в таким образом смонтированной фс обычно некая >> "подстановка"/имитация, демонстрируемая драйвером ФС, а какие права на вновь сохданные >> "здесь" фс-объекты увидят пользователи оригтнальныъ реализаций "там" (на винде, на том >> конце smb:// протокола [да, я слышал краем уха про посикс-расширения, но >> не видел ни разу]) -- может быть непредсказуемо и неожидаемо. > Само себе это понятно. Но в контексте вопроса, это означает, что права > на папки лежащие внутри раздела с неродной ФС поменять не факт > что удастся?В опциях монтирования у них как правило бывает uid= gid=, что расставляет разрешения на всю неродную fs. А на саму папку, которая находится на родной ФС > и к которой смонтирован раздел? Права запоминаются на корне fs которую примонтировали, после отмонтирования будут права на папку в которую монтировали, которые были. >[оверквотинг удален] >> пока оно "взлетит" с доп.опциями >> umask в шеде и umask= опция монтирования (если она вообще есть) - >> разные вещи. > А можно поменять умолчание umask-опции монтирования? На 0000. Для меня это было > гораздо более предсказуемым поведением ОС. >> Хотелось бы также услышать, чего же вы желаете добиться. Не "поменять права >> на ...", а в результате этого -- "дать доступ пользователю не-root-у >> к разделу на флэшке", например? >> ...ext3 тоже на флэшке, например? > Так и есть, хочу дать права пользователям (minidlna и ..debian-transmission вроде)
|