2

Существует множество подобных вопросов о суперпользователе, поэтому я постараюсь сделать это быстро, рассказав вам, что это не так:

  • Здесь нет заявки. Просто пользователь и файловая система.
  • Я могу войти в систему как пользователь root и мой пользователь без полномочий root имеет полный доступ sudo.
  • Насколько я знаю, эта проблема существует только в одном каталоге (хотя, учитывая достаточно времени, я думаю, что могу воссоздать это поведение в любом каталоге - подробнее об этом ниже).
  • Никаких странных настроек файловой системы, масок или нечетных схем доступа пользователей или каталогов - у меня есть эта система, и другие люди с ней не взаимодействуют.

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

Допустим, это свежая установка, для этого примера. Сценарий работает некоторое время. Но по прошествии некоторого периода времени никакие файлы больше не могут быть созданы в целевом пути любым пользователем, используя любой метод. Я пробовал touch, tar, zip и т.д. Ничего не работает. Tar и zip потерпят неудачу с ошибками ввода / вывода, touch работает нормально, но файл не создается. В этом пути назначения, и только в этом пути. Создание / изменение / удаление файла отлично работает везде в файловой системе (если это происходит в другом месте, это бессимптомно).

права доступа к каталогу выглядят так через ls -al : drwxrwxr-x. - принадлежит моему некорневому пользователю и его группе.

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

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

Сведения о системе:

  • CentOS 2.6.32-431.3.1.el6.x86_64
  • Файловая система ext4
  • 400 ГБ бесплатно в / (лвм)

Любые идеи или мысли о том, что можно попробовать, будет принята с благодарностью. Я с радостью расскажу подробнее, если нужно, но я хотел бы остановиться на этом кратко для начала.

Спасибо за ваше время!

РЕДАКТИРОВАНИЕ 20.10.14: Все еще нет ответов здесь. Могу ли я получить кому-нибудь больше информации?

РЕДАКТИРОВАТЬ 10/8/14: Добавление информации в соответствии с просьбой в комментариях:
$ ls -l
всего 0

$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
vg_omega1 1 2 0 wz - n- 464.24g 0

РЕДАКТИРОВАТЬ 10/7/14: Добавление информации в соответствии с просьбой в комментариях:
Результаты монтирования:
/dev/mapper/vg_omega1-lv_root on / type ext4 (rw)
proc on / proc тип proc (rw)
sysfs on / sys type sysfs (rw)
devpts для /dev/ pts введите devpts (rw, gid = 5, mode = 620)
tmpfs для /dev/ shm типа tmpfs (rw, rootcontext = "system_u:object_r:tmpfs_t:s0")
/dev/ sda1 on / тип загрузки ext4 (rw)
нет в / proc / sys / fs / binfmt_misc тип binfmt_misc (rw)

Дорожка:
/ Главная / [имя пользователя] / Сохранённые игры / синхронизации

РЕДАКТИРОВАТЬ 06/6/14: Дальнейшее тестирование показывает, что я, очевидно, могу создавать подкаталоги и символические ссылки просто отлично. Эта проблема, кажется, ограничена обычными файлами.

1 ответ1

0

Я не могу комментировать, так как у меня нет представителя, но, увидев вывод вашего mount похоже, что у вас запущен SELinux. Исходя из опыта, трудно отследить такие странные вещи, как эта, если вы не знакомы с SELinux. 5+ лет работы с ним научили меня хитрости или двум.

tmpfs для /dev /shm типа tmpfs (rw, rootcontext = "system_u:object_r:tmpfs_t:s0")

Вы также упоминаете, что используете rsync, и эта проблема "исчезает и возвращается снова". Ваши параметры SELinux установлены по умолчанию? (применяется снова после перезагрузки), и вы (иногда) переводите SELinux в разрешающий режим (5 минут или 10 дней и т. д.) после перезагрузки?

sudo getenforce

Если результат этого является enforcing , и если у вас SELinux установлен режим принудительного применения по умолчанию, есть вероятность, что вы сталкиваетесь с отказами политики SELinux.

Ссылка на руководство администратора RedHat 6 - Ch 12 - rsync

если ты

ls -lZ /home/[username]/savegames/sync 

Что такое метка контекста? Это должно быть что-то вроде public_content_t. Это может быть user_home_t, что означает, что многим закрытым процессам SELinux будет отказано в доступе. В /var/log/audit/audit.log будут сообщения об отказе

Если SELinux действительно является виновником, обратитесь к руководству по устранению неполадок CentOS SELinux, чтобы узнать, как это решить. Вы могли бы:

  • Переведите SELinux в разрешительный режим и посмотрите, исчезнет ли ваша проблема. Переведите его обратно в принудительный режим, и ваша проблема вернется. Не долгосрочное решение, так что ...
  • Либо переименуйте контекст папки /home /[username] /savegames /sync (в public_content_t или аналогичный), либо
  • Создайте политики, которые позволят вашим скриптам /процессам работать с вашей папкой (audit2allow). Это выглядит устрашающе, но не невозможно.

ПОЖАЛУЙСТА. НЕ ВЫКЛЮЧАЙТЕ SELINUX.

Что ж, сказав, что, если вы единственный, кто использует систему, и вы не обслуживаете веб-сайты или FTP или что-то еще, хорошо, возможно, оставьте это в разрешающем режиме, но хорошая практика предлагает вам изменить свою политику, чтобы дать вам ключ к двери, а не просто снять дверь с петель и отложить в сторону :-)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .