/ bin / sh: плохой интерпретатор: разрешено при установке Postgres

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

У меня есть vps Linux x64 (v2.6.18; CentOS 6.7). Я работаю над конкретным проектом (OpenClinica) для клиента, и мне нужно установить Postgresql версии 8.4 (старая версия, я знаю) непосредственно из .bin-файла. Файл выглядит как postgresql-8.4.1-1-linux-x64.bin . Насколько я понял, этот .bin файл создает некоторые .sh файлы в /tmp/postgresql_installer/ .

Мне также сказали, что этот файл работает нормально и уже успешно выполнил установки Postgres во многих других системах Linux (CentOS), работающих под управлением OpenClinica.

Когда я запускаю его как root в командной строке, набрав это

 ./postgresql* --mode text 

Я получаю разочаровывающее сообщение ниже.

 Error: Error running /tmp/postgresql_installer/getlocales.sh : /bin/sh: /tmp/postgresql_installer/getlocales.sh: /bin/sh: bad interpreter: Permission denied 

Что я уже проверил (смотрю на этом и других форумах)

  1. первая строка getlocales.sh имеет #!/bin/sh в ней

  2. есть ссылка sh -> bash* at /bin

     root@vps [/bin]# ls -l sh lrwxrwxrwx 1 root root 4 Nov 14 12:29 sh -> bash* 
  3. sestatus

  4. Я дал chmod x разрешение на postgres*.bin прежде чем я запустил его.

  5. Я даже пытался запустить postgres*.bin от ~/ без успеха.

Есть идеи?

  • Установите apache, php и mysql на CentOS VPS
  • Расширение виртуального жесткого диска для CentOS
  • psmouse serio1 неизвестное оборудование и мышь / тачпад работают ТОЛЬКО в режиме спасения
  • Могу ли я настроить уведомления об ошибках на конкретную запись cronjob, чтобы перейти на другой адрес электронной почты?
  • Centos 6.7 сломанный Судо
  • Yum, принудительно обновить зависимости
  • Фиксирование неудачного CentOS 5.9 Шаг Grub
  • Настройка CentOS7.0 - размер раздела
  • One Solution collect form web for “/ bin / sh: плохой интерпретатор: разрешено при установке Postgres”

    Как было сказано, проблема заключалась в том, что / tmp смонтирован с помощью noexec. Объяснение довольно просто, некоторые скрипты установки распаковывают исполняемые файлы / скрипты в / tmp, а затем пытаются запустить их.

    Я на самом деле случайно наткнулся на эту проблему, когда-то несколько лет назад, когда я изменил пару серверов / tmp на noexec по соображениям безопасности, а затем скрипты установки и обновления некоторых пакетов Debian перестали работать. Поскольку я ее специально изменил, было довольно легко определить проблему в то время.

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

    Linux и Unix - лучшая ОС в мире.