Вопросы Теги

Ошибки Доступа запрещен на некоторых файлах в совместно используемой папке

Плохо записанный об/мин .spec файлы (или даже правильно написанные с опечаткой) может сделать неподходящие вещи, такие как:

  • Установите непосредственно на рабочей системе вместо к песочнице
  • Спам отпуска в файловой системе
  • Случайно выполните противные команды, такие как: rm -rf ${RPM_BUILD_ROOT}

Там не входит в процесс сборки об/мин, который на самом деле должен базироваться доступ. Так, мы должны выполнить стандартную процедуру, "Если она не должна базироваться разрешение, она не работает как корень" при создании RPMs.

Это избегает противных несчастных случаев и неожиданностей.

0
задан 9 July 2009 в 00:16
3 ответа

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

1
ответ дан 4 December 2019 в 23:30
  • 1
    You' ре близко. Файлы, вставляемые в единственном объеме (или доля), сохранят полномочия, которые они были присвоены/наследованы во время создания, даже если they' ре переместилось в папку, которая присвоила бы различные полномочия им (если они были созданы в той папке), позже. Наследование разрешения происходит в создание только! При копировании / движущиеся файлы между доли или объемы являются создаванием / копия (и удалите источника при перемещении), таким образом, наследование разрешения действительно происходит при тех обстоятельствах. Взгляните на: serverfault.com/questions/31709/… –  Evan Anderson 9 July 2009 в 00:33

Это не действительно ответ, но дополнительная информация (не может использовать комментарий из-за символьного предела). Я все еще пытаюсь понять и решить эту проблему.

Вот то, на что полномочия "плохого" файла похож в CACLS (полномочия предотвращают копирование с другой машины):

C:\...\Mail\descmap.pce BUILTIN\Administrators:F
                        NT AUTHORITY\SYSTEM:F
                        MARS\Tim:F
                        BUILTIN\Users:R

Вот то, на что похож "хороший" файл:

C:\...\Mail\In.mbx Everyone:C
                   BUILTIN\Administrators:F
                   NT AUTHORITY\SYSTEM:F
                   MARS\Tim:F
                   BUILTIN\Users:R

Вот то, на что похожи полномочия "Почтовой" (родительской) папки:

C:...>cacls mail
C:...\Mail Everyone:(OI)(CI)C
           BUILTIN\Administrators:F
           BUILTIN\Administrators:(OI)(CI)(IO)F
           NT AUTHORITY\SYSTEM:F
           NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
           MARS\Guest:F
           CREATOR OWNER:(OI)(CI)(IO)F
           BUILTIN\Users:R
           BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                     GENERIC_READ
                                     GENERIC_EXECUTE

           BUILTIN\Users:(CI)(special access:)
                             FILE_APPEND_DATA

           BUILTIN\Users:(CI)(special access:)
                             FILE_WRITE_DATA

"Everyone:C" и атрибуты "BUILTIN\Administrators:F" так или иначе удалены из проблемных файлов. Различные файлы затронуты в разное время. Кажется, нет никакой непротиворечивости.

0
ответ дан 4 December 2019 в 23:30

Это не решение, но что-то для обмена мнениями на...

У меня есть почти та же точная проблема. Однако в моем случае, у меня был идентификатор пользователя, входящий в сервер Samba-3, действующий как PDC (таким образом, мне соединили машины с доменом).

Этот идентификатор пользователя мог получить доступ к файлу от поля WinXP, но на Win7-PRO машине они получат ошибку доступа запрещен. Файл не перемещался от доли до доли или папки к папке. Это была просто общедоступная папка, что у всех в компании был доступ также.

Я попробовал все для разрешения и единственная вещь, которую я нашел, повторно подготавливал рабочую станцию с чистой копией Windows 7, устранил проблему.

В моем случае взаимодействие Windows7 с Samba, казалось, было проблемой. Интересный то, что у меня есть другие поля Win7, что проблемы не произошло на с другими пользователями, но этот конкретный конкретный идентификатор пользователя только имел проблему на полях Win7.

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

Это было, если эти окна, 7 рабочих станций заставили проблему появляться с идентификатором пользователя, который там после того, как это переместилось с тем идентификатором пользователя в другого Win 7 рабочих станций.

Переподготовка одной рабочей станции Win 7 заставляет проблему уйти.

0
ответ дан 4 December 2019 в 23:30

Теги

Похожие вопросы