Думаю в данном случае изначально подошли неправильно к решению или рассмотрению данной проблемы.
Проблема заключается не в том, форум не работает из-за настроек хостинга, а из-за проблемы связаной с изменениями в версии 3.0.4.
Данная проблема рассматривалась много раз и если поискать на офф форуме, она до сих пор полностью не устранена полностью.
Так вот суть проблемы - в новой версии были изменены параметры (функция) выставления прав. До этой версии права указывались как бы напрямую (т.е. задавались в конфигурации, как например:
WAS: @chmod($this->cache_dir . 'data_global.' . $phpEx, 0777);
NEW: @chmod($this->cache_dir . 'data_global.' . $phpEx, 0666);
И подобными образом.
В новой версии права задаются с помощью директив (флагов):
@define('CHMOD_ALL', 7);
@define('CHMOD_READ', 4);
@define('CHMOD_WRITE', 2);
@define('CHMOD_EXECUTE', 1);
Т.е. права определяются установкой флагов: CHMOD_READ + CHMOD_WRITE - получаем 6 и т.д.
Так вот в результате получилось так, что временные файлы стали создаваться с правами 620 (об этом указано в ошибке 39355).
Т.е. изначально стоят параметры CHMOD_READ+CHMOD_WRITE и CHMOD_WRITE = 620
Как указывал:
в данной проблеме php работает именно как модуль (Apache Handler) - плюсы и минусы того или иного способа расписывать не буду - каждый склоняется к своему (но с опытом использования разных скриптов лично я пришел к выводу, что большинство из них требует, чтобы апатч работал именно как модуль, а не как cgi, и к сожаление таких случаев много).rxu писал(а):Почему наши хостеры так любят запускать php в режиме Apache Handler, а в США как правило используют режим CGI/FastCGI.Во втором случае подобных проблем не бывает в принципе.
Поискав на форуме решения - пробовал использовать все варианты (1,2,3,4 - указанные пользователем "Hatch")
Первый и второй вариант - никаких решений не дал вообще. Третий способ - это способ для версий ниже. 4-й способ не помог, т.к. изначально все было указанно верно.
Было найдено решение с модификацией файла /includes/acm/acm_file.php, в нем как я понял и определяются права доступа, соответствующие значения были изменены, в результате были получены права досутупа 660 (не составит проблем сделать и 770), но в любом случае последний 0 - определяет пользователя - вот в нем и проблема (до версии 3,0,4 - права выставлялись правильно на все файлы кеша, т.к. сам использую данный форум и до последнего обновления все работало нормально).
Далее - т.к. php работает как модуль Apache он запускается от отдельного пользователя, соответственно все файлы созданные скриптом создаются именно от этого пользователя. Все остальное же работает от пользователя аккаунта. В результате получается некоторая нестыковка прав доступа, данную проблему многие провайдеры решают по разному - у некоторых есть специальная опция в панели управления для сбрасывания прав, у некоторых запускается скрипт. В данном случае скрипт меняет только группу и пользователя на правильные, но не права доступа к файлу.
Далее по файлам - как известно права 660 означают - 6(владелец файла)6(група)0(все остальные пользователи), т.е. получается все другие пользователи - отличные от владельца и группы не имеют прав даже на чтение данного файла - что пренципиально не правильно (если я не правильно выразился поправьте пожалуйста).
Так вот решение данной проблемы нужно искать в новой функции задания прав доступа к файлам.
Так же, к сожалению до конца не понятно следующее - у некоторых других пользователей, которые обращались с данной проблемой на офф сайт - права к файлам выставлялись как 755 (и в основном решение проблемы для них) - права как я указывал можно исправить в файле acm_file.php. Но в данном случае файлы создаются с совсем другими правами 720 или 620 - возможно виноват какой-то модуль или какая-то модификация - установить это не удалось.
P.S. надеюсь выше сказанное приблизит к решению данной проблемы, а не зациклиться на том, что во всем и всегда виноват хостер, если у него настройки для какого-то скрипта не подходят - как вы выражаетесь проблема хостера, а не разработчика скрипта, который не учел данный параметр. В это время другой разработчки учел данный параметр и для него не нужно, чтобы он был активирован, т.к. это приносит много проблем - в этом случае кто виноват?
В любом случае кто виноват в данном случае разработчки или какие-то настроки на хостинге - выносить окончательного решения НЕ БУДУ! - Ваше право решать и у каждого свое мнение. Я только надеюсь, что суть проблемы будет понятна, найдена и решена, а не просто выяснение - кто, зачем и почему.