Проблема с CHMOD (PHP 5.x)

Статус
В этой теме нельзя размещать новые ответы.

SAKH

Постоялец
Регистрация
15 Янв 2008
Сообщения
77
Реакции
11
Здравствуйте уважаемы форумчане!
Искал, спрашивал везде... не помогло.

У меня такая проблема.
Хост РБК, (PHP 5.x стоит, но есть и ранние версии.. сам выбираешь)
Разработчик движка InstsntCMS требует выставления на папки прав 777 на папки "images", "includes", "upload". , а хостер требует 755.

Но! Если на папках (примеру "upload") стоят права 755, то при загрузке рисунка на форум, папку /upload/forum не загружается вобще.
Если ставлю 777 на папки (как требует разработчик движка), то рисунок грузится в нужную папку, но при этом права на него устанавливаются 600, а не 644. Поэтому рисунок на сайте после загрузки не доступен и появляется только при ручной смене прав на 644 (файла картинки)и это при условии 777 на upload.
То капча не показывается при 777, то еще чего....

Разработчик движка ответил, что права должны на сервере назначаться, а не скриптом.
Хостер ответил мне, что на ихном массовом хостинге php скрипт сам должен выставлять верные права.
После этого разработчик движка в файле imginsert.php прописали: ( @chmod("/upload/$place/$filename", 0644), чтобы скрипт назначал права.

Заменил файл imginsert.php в /core/ajax, /upload/ вернул на 777. Опять:картинка то сама загрузилась по адресу , но не отобразилась, т.к. на нее права выставились 600. Сменил руками на 644 - появилась!

А вот хостер тестовую форму поставил мне и там все проходит нормально, на папках стоит 755 и файлы грузит с правами 644....


Не знаю в чем тут дело.... хост...движок...
Помогите, как тут и что сделать... А то разработчик развел руками, а хостер ушел в тину.....
 
Убери погашение ошибки у смены прав и увидишь в чем трабла.
PHP:
chmod("/upload/$place/$filename", 0644)
Скорее всего php не есть владелец файлов, залитых по ftp (папки самого движка).
 
  • Нравится
Реакции: SAKH
как установлен PHP - mod_php или CGI?

Да если б я знал..
Искал у хостера, нашел только вот это:
Путь к perl /usr/bin/perl
Путь к date /bin/date
Путь к mail /usr/bin/mail
Путь к sendmail /usr/sbin/sendmail

Доступные обработчики*:
/usr/local/apache/bin/php-cgi - Обработчик PHP версии 4
/usr/local/apache/bin/php-cgi.4.4 - Обработчик PHP версии 4.4
/usr/local/apache/bin/php-cgi.5 - Обработчик PHP версии 5
/usr/bin/perl - Perl
/usr/local/bin/python - Python

У меня PHP версии 5 стоит.
--
Убери погашение ошибки у смены прав и увидишь в чем трабла.
Дак этого исправления изначально не было и оно не идет со скриптом, его специально мне скинули и я его ставил, убирал...
Я же не спец в этой сфере, потому и спрашиваю. Могу сделать что то простое, а если проблема, то как объяснят.... тогда сделаю.
 
я же написал что сделать (убрать собаку) перед исправлением, которое дал вам разраб.
 
  • Нравится
Реакции: SAKH
Проблема скорее всего потому, что файл создается процессом PHP, который запущен как CGI, а читается файл при отдаче браузеру процессом Apache. Они скорее всего и в группах разных, поэтому то, что закачано скриптом не доступно Apache. Похоже, тут намечается целая тенденция с подобного рода проблемами. Уже не первый раз встречаю. Думаю все из-за того, что PHP5 проапгрейдили и оставили один PHP как модуль апача, а второй - как CGI.
 
  • Нравится
Реакции: SAKH
Если убираю погашение ошибки, то фото вобще не загружается и показывает:
Ошибка! {Object Error}

А с @ (вобще с этим исправлением, а также и без исправления т.е. с родным файлом imginsert.php) грузится, но не отображается, т.к. права опять 600.

А что касается версии PHP, то до 5х у меня стояла 4.3.9 и то же самое все и было.
 
SAKH, легче заказать доработку/исправление багов в соотв. разделе. Честно.. Или показывай весь двиг, с задействованными классами - или топик нуна закрывать.
 
а как по мне, то тут куча вариантов.

вот почему хостеровское работает? скрипт видно с рута (к примеру) скопирован. а при выполнении - присваивается что-то, что дает chmod как-то иначе ставить.

плюс рнр может быть в safe

плюс htaccess может быть прописан как-то...

да и изначальные аттрибуты - это хостер сам выставляет. в целях безопасности....
 
Jeurey SAKH, легче заказать доработку/исправление багов в соотв. разделе. Честно..
Да я не против конечно, если уж совсем иных вариантов нет. Закрывать или нет, это конечно вам виднее. Если считаете, что все-равно никчему не прийдем, то конечно нет смысла дальше.
Хотя интересно получается... вроде как надо бы к разработчику с этим вопросом. Но его совет.., да и еще других - менять хостинг. Может и так, может нет, а вдруг на другом хосте тот же гемор.

Jeurey Или показывай весь двиг, с задействованными классами - или топик нуна закрывать.

А что конкретно, куда и как выкладывать то?
Сайт к примеру находится по адресу: _www.sakhportal.com (хотя это алиас), а так _info-sakh.com

Xenos а как по мне, то тут куча вариантов.

вот почему хостеровское работает? скрипт видно с рута (к примеру) скопирован. а при выполнении - присваивается что-то, что дает chmod как-то иначе ставить.

плюс рнр может быть в safe

плюс htaccess может быть прописан как-то...

да и изначальные аттрибуты - это хостер сам выставляет. в целях безопасности....

Ну htaccess идет вместе с движком, его разработчик как прописал, так и есть.

А в отношении хостера.. Пес его знает, чего ему уже сказать после того, как он форму вкинул на сайт и на ней работает. Хотя я к примеру не могу по ФТП удалить одну папку, которую сам туда ложил!?

А с картинками тоже... Ведь грузятся они и все нормально кажет в фотогалерее и в новостях. А вот в блогах и форуме и баннерах нет!
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху