Полностью устраивает, только на хостинге, при попытке закинуть фотку, вываливается 502 Bad Gateway. Эти редиски уже несколько дней не могу решить эту проблему. Поэтому я решил, что быстрей будет поэкспериментировать с аналогичными модулями.
Вот еще. При попытке закинуть фотку в log пишется:
move_uploaded_file() [function.move-uploaded-file]: Operation not permitted в файле /pub/home/plafol58/htdocs/includes/file.inc в строке 241.
// if (!move_uploaded_file($_FILES["files"]["tmp_name"][$source], $file->filepath)) {
Такой патчик.
Почему вылетает все это дело при функции move_uploaded_file() в данном случае не вижу смысла. Это абсолютно точно баг данного модуля, т.к. сама функция работает и работает корректно. Если у вас есть желание, можете расковырять систему нотификации ошибок друпала на предмет хэдеров, грабли где-то там.
Спасибо за выбор Valuehost. <-------- Издеваются редиски
Я не большой знаток PHP, но в решении данного вопроса тоже заинтересован, ибо размещаюсь на Валуе.
Вот в доке про move_uploaded_file() увидел такое: "Примечание: если safe mode включён, PHP проверяет, имеют ли файл(ы)/директории, с которыми вы собираетесь работать, тот же UID, что и выполняемый скрипт.
Примечание: на move_uploaded_file() не действуют нормальные safe-mode UID-ограничения. Это не небезопасно, поскольку move_uploaded_file() работает только с файлами, загруженными через PHP".
Вот еще на Hostforum нашел обсуждение проблемы, связанной с move_uploaded_file(): "Сообщение от tmax
а почему move_uploaded_file() создает файл с владельцем nobody, а не моим username?
фактически PHP копирует файл из /tmp в каталог куда мне надо, и чтоб его удалить или изменить прийдется действовать только скриптами, а через шелл не получится."
Покрышев тогда ответил, что "Этой проблемой сейчас занимаемся. Поправим - сегодня-завтра.", но, возможно, завтра еще не наступило и наша проблема - отголоски той.
Проблема с владельцем и правами поправлена.
Также из open_basedir исключен каталог /tmp
+
upload_tmp_dir = /pub/home/login/tmp
К тому же, я проверил, владелец файлов в папке tmp - Я.
Вообще какая-то белиберда. Зарегистрировался на бесплатном хостинге. Вообще никаких проблем. Все работают. А поддержка меня мурыжит, что модуль image глючный!!!
Попробовал приведенный вами "патчик". Картинки создаются успешно, но заметил 3 "странности":
1) после создания выдается сообщение "Выбранный файл /pub/home/my_login/tmp/fileYse6IW не удается скопировать."
2) в каталоге /files/images/temp остаются файлы имяфайла.thumbnail.jpg и имясайта.preview.jpg
3) после удаления материала все эти файлы + файл имяфайла.jpg также остаются неудаленными.
Скорее всего проблема в том, что апач вертится под nobody а владелец папки files отличен от него.
>>drwsrwx--- 3 plafol 8080 512 Jan 18 11:50 files
говорит о том, что запись и чтение файлов разрешено только пользователю и его группе, а для всех разрешения отсутствуют! это соответствует 774
Чего бы еще загнуть в службу поддержки хостинга??
Они постоянно ссылаются на корявость модуля image. Но логично предположить, что если бы это было так, то такие же точно проблемы были бы на всех хостингах.
Поставил на каталог files и files/images и даже на /tmp права 777 - не помогает, как и valen. В папке tmp создаются временные файлы jpg, но переместить их функцией move_uploaded_file() не удается.
Апач - под nobody точно (User/Group - nobody(65534)/8080). Safe mode - Off, safe_mode_gid - Off, safe_mode_exec_dir и safe_mode_include_dir - no value, file_uploads - On, upload_max_filesize - 2M, upload_tmp_dir - /pub/home/my_login/tmp... Что еще может влиять?
Похоже, действительно, на разных владельцев. Но саппорт-то не признается
Возможно, т.к. это нередко становится причиной некоторых похожих проблем. Этот вариант решается выставлением прав 4770 на папку. Просто скрипты если что-то создают, то от nobody, с правами 0****.
Интересно, а стандартный модуль upload работает? там используется функция copy, а временный файл остается на месте!
Может проблема действительно в move_uploaded_file
А что есть "права 4770"?
Пробовал и 477 и 770 - никаких изменений. Точнее 477 мне не удалось выставить через FTP менеджер FARа (делает 577 почему-то).
Даже при создании материала типа page выдает сообщение типа "Выбранный файл /pub/home/aquatica/tmp/fileEqHWhC не удается скопировать." Создается какой-о файлик в 282 байта, который не перемещается.
Если добавлять прикрепленные изображения, то симптоматика та же - пустая страница и материал не создается. Только временный файл в /tmp
Что-то валуи наворотили при обновлении, раньше все работало.
Забавный баг, делов том, что file_check_upload вызывает move_uploaded_file(), но и меняет $_FILES и соответственно файл не прходит обязательную валидацию, которая отличает move_uploaded_file() от остальных файловых функций!
Файл сохраняется во временной папке до сохранения ноды, а при сохранении вызывается именно copy для всех загруженных предварительно файлов - поэтому и работает!
Какая версия php установлена? может в этом дело...
Да уж. Та отписка саппорта, которую вы приводили, основана на очень странной "логике". Это типа модуль image виноват. Но там лишь вызывается стандартная php-ная функция move_uploaded_file() и, если она не сработала, выдается сообщение об ошибке.
Функция, по мнению саппорта, срабатывает нормально. Где ж нормально, если файл не перемещается (или, в лучшем случае, перемещается, но остается временный файл)?
На http://www.hostforum.ru/ не писали? Может быть, если перевести этот вопрос из приватной переписки в публичное обсуждение, так у саппорта будет мотив решить проблему?
Саппорт предложил мне следующее решение проблемы: в файле includes/file.inc перед строкой if (!move_uploaded_file($_FILES["files"]["tmp_name"][$source], $file->filepath)) {
вставить строку error_reporting('E_ALL ^ E_NOTICE');
Спасибо, конечно, саппорту за более-менее пригодное решение. Изображение прикрепляется, хотя и с огрехами. В частности, остается заблокированным временный файл в /tmp размером 282 байта. И пользователю выдается сообщение типа "Выбранный файл /pub/home/aquatica/tmp/fileJhtBAh не удается скопировать."
(аналогично и при удалении файлов).
Тем не менее, предложенное решение, конечно, довольно странное. Во-первых, на других хостингах по всему миру модуль image и функция move_uploaded_file прекрасно работают безо всяких "костылей" (и раньше на Валуе тоже работали). Мне хотелось бы добиться нормальной работы от хостинга.
Во-вторых, насколько я понимаю, директива error_reporting('E_ALL ^ E_NOTICE'); управляет уровнем контроля за ошибками (показывать все, кроме извещений), т.е. будут ли выводиться сообщения об ошибках. Но сами ошибки-то она не исправляет? Неудаленные временные файлы - тому подтверждение.
Еще вопросы возникают. Нужно ли после использования move_uploaded_file устанавливать исходный уровень контроля ошибок? Ну и что, теперь везде, где встречаются move_uploaded_file и подобные функции, хачить код?
Ответ саппорта про сообщения (warnings) о невозможности переместить или скопировать файл: "как выяснилось, этот warning каким-то образом попадает перед header'ом, возращаемым скриптом и сервер не может такие хэдеры разобрать. Возникает это именно на Друпале, именно в модуле image".
Добавлю - "и именно на Valuehost"
Продолжение банкета - завтра. Просили снова поднять вопрос и обещали разобраться.
Вчера ковырял загрузку файлов - интересный для меня момент выяснился, оказывается, что файл копируется 2жды!
первый раз из временного каталога системы во временный каталог друпала (у меня они не совпадают), а потом уже попадает в положенное ему местов files - может в этом беда, что промежуточный каталог не имеет нужных прав!
Частичная. У меня, например, изображения добавляются, но при этом появляются сообщения типа "Выбранный файл /pub/home/my_login/tmp/fileWwRT3J не удается скопировать." Временные файлы перестали появляться в /tmp при добавлении, но при удалении появляются аж по три штуки.
Можно, конечно, выключить в настройках Drupal выдачу извещений на экран (только в логи). Но это все же непорядок.
Еще раз проверю. Но когда пробовал сообщения не появлялись.
На вопрос, что же все таки было изменено. Получил ответ:
"Не буду вдаваться в технические тонкости, могу сказать, что проблема была в специфике принципов построения пользовательских аккаунтов, были внесены изменения в код php."
А у меня картинки качаются нормально, зато 502 получаю пр ипопытке голосования в опросе (модуль Poll).
Хосетр - валухост. Наверное, и этот модуль "глючный"
Комментарии
А чем он не устраивает?
Полностью устраивает, только на хостинге, при попытке закинуть фотку, вываливается 502 Bad Gateway. Эти редиски уже несколько дней не могу решить эту проблему. Поэтому я решил, что быстрей будет поэкспериментировать с аналогичными модулями.
Вот еще. При попытке закинуть фотку в log пишется:
move_uploaded_file() [function.move-uploaded-file]: Operation not permitted в файле /pub/home/plafol58/htdocs/includes/file.inc в строке 241.
Права на папку files 777, на tmp 777
а кто владелец папок?
Пардон, за безграмотность. Где посмотреть?
ls -l в консоли, либо в тотале - Фаил->Атрибуты
А лучше пуститу туда знакомого линуксоида на минут 20
Линуксоид - это конечно хорошо, НО хотелось бы самому разобраться.
Вот папка files. Владелец получаюсь - Я.
drwsrwx--- 3 plafol 8080 512 Jan 18 11:50 files
Вот что хостинг отвечает:
Кто, что может прокомментировать?
Дорогой Клиент.
Спасибо за Ваше письмо.
/pub/home/plafol58/htdocs/includes/file.inc:242
/* VH Patch */
exec("mv ".$_FILES["files"]["tmp_name"][$source]." ".$file->filepath, $mv_result, $mv_bool);
if($mv_bool!=0){
/* End VH Patch */
// if (!move_uploaded_file($_FILES["files"]["tmp_name"][$source], $file->filepath)) {
Такой патчик.
Почему вылетает все это дело при функции move_uploaded_file() в данном случае не вижу смысла. Это абсолютно точно баг данного модуля, т.к. сама функция работает и работает корректно. Если у вас есть желание, можете расковырять систему нотификации ошибок друпала на предмет хэдеров, грабли где-то там.
Спасибо за выбор Valuehost. <-------- Издеваются редиски
Я не большой знаток PHP, но в решении данного вопроса тоже заинтересован, ибо размещаюсь на Валуе.
Вот в доке про move_uploaded_file() увидел такое: "Примечание: если safe mode включён, PHP проверяет, имеют ли файл(ы)/директории, с которыми вы собираетесь работать, тот же UID, что и выполняемый скрипт.
Примечание: на move_uploaded_file() не действуют нормальные safe-mode UID-ограничения. Это не небезопасно, поскольку move_uploaded_file() работает только с файлами, загруженными через PHP".
На вашем сервере safe-mode не включен?
safe_mode в положении off
Вот еще на Hostforum нашел обсуждение проблемы, связанной с move_uploaded_file(): "Сообщение от tmax
а почему move_uploaded_file() создает файл с владельцем nobody, а не моим username?
фактически PHP копирует файл из /tmp в каталог куда мне надо, и чтоб его удалить или изменить прийдется действовать только скриптами, а через шелл не получится."
Покрышев тогда ответил, что "Этой проблемой сейчас занимаемся. Поправим - сегодня-завтра.", но, возможно, завтра еще не наступило и наша проблема - отголоски той.
Вот его ответ:
Проблема с владельцем и правами поправлена.
Также из open_basedir исключен каталог /tmp
+
upload_tmp_dir = /pub/home/login/tmp
К тому же, я проверил, владелец файлов в папке tmp - Я.
Вообще какая-то белиберда. Зарегистрировался на бесплатном хостинге. Вообще никаких проблем. Все работают. А поддержка меня мурыжит, что модуль image глючный!!!
Попробовал приведенный вами "патчик". Картинки создаются успешно, но заметил 3 "странности":
1) после создания выдается сообщение "Выбранный файл /pub/home/my_login/tmp/fileYse6IW не удается скопировать."
2) в каталоге /files/images/temp остаются файлы имяфайла.thumbnail.jpg и имясайта.preview.jpg
3) после удаления материала все эти файлы + файл имяфайла.jpg также остаются неудаленными.
Скорее всего проблема в том, что апач вертится под nobody а владелец папки files отличен от него.
>>drwsrwx--- 3 plafol 8080 512 Jan 18 11:50 files
говорит о том, что запись и чтение файлов разрешено только пользователю и его группе, а для всех разрешения отсутствуют! это соответствует 774
Чего бы еще загнуть в службу поддержки хостинга??
Они постоянно ссылаются на корявость модуля image. Но логично предположить, что если бы это было так, то такие же точно проблемы были бы на всех хостингах.
Поставил на каталог files и files/images и даже на /tmp права 777 - не помогает, как и valen. В папке tmp создаются временные файлы jpg, но переместить их функцией move_uploaded_file() не удается.
Апач - под nobody точно (User/Group - nobody(65534)/8080). Safe mode - Off, safe_mode_gid - Off, safe_mode_exec_dir и safe_mode_include_dir - no value, file_uploads - On, upload_max_filesize - 2M, upload_tmp_dir - /pub/home/my_login/tmp... Что еще может влиять?
Похоже, действительно, на разных владельцев. Но саппорт-то не признается
Ответ хоста по поводу nobody:
Возможно, т.к. это нередко становится причиной некоторых похожих проблем. Этот вариант решается выставлением прав 4770 на папку. Просто скрипты если что-то создают, то от nobody, с правами 0****.
Интересно, а стандартный модуль upload работает? там используется функция copy, а временный файл остается на месте!
Может проблема действительно в move_uploaded_file
Включил Upload. Создаю материал, цепляю к нему файл и ................................
move_uploaded_file() [function.move-uploaded-file]: Operation not permitted в файле /pub/home/plafol58/htdocs/includes/file.inc в строке 241.
НО файл цепляется. Материал создается с файлом, файл можно загрузить.
А что есть "права 4770"?
Пробовал и 477 и 770 - никаких изменений. Точнее 477 мне не удалось выставить через FTP менеджер FARа (делает 577 почему-то).
Даже при создании материала типа page выдает сообщение типа "Выбранный файл /pub/home/aquatica/tmp/fileEqHWhC не удается скопировать." Создается какой-о файлик в 282 байта, который не перемещается.
Если добавлять прикрепленные изображения, то симптоматика та же - пустая страница и материал не создается. Только временный файл в /tmp
Что-то валуи наворотили при обновлении, раньше все работало.
Задал этот же вопрос в службу поддержки. Ответили, мол сиди не дрыгайся мы все сами поставим.
После этого ничего не заработало, а в файле .bash_history появились такие строки "chmod 4770 files".
Забавный баг, делов том, что file_check_upload вызывает move_uploaded_file(), но и меняет $_FILES и соответственно файл не прходит обязательную валидацию, которая отличает move_uploaded_file() от остальных файловых функций!
Файл сохраняется во временной папке до сохранения ноды, а при сохранении вызывается именно copy для всех загруженных предварительно файлов - поэтому и работает!
Какая версия php установлена? может в этом дело...
PHP Version 5.2.5
Похоже, что данная проблема не имеет решения. Служба поддержки отмахивается.
Да уж. Та отписка саппорта, которую вы приводили, основана на очень странной "логике". Это типа модуль image виноват. Но там лишь вызывается стандартная php-ная функция move_uploaded_file() и, если она не сработала, выдается сообщение об ошибке.
Функция, по мнению саппорта, срабатывает нормально. Где ж нормально, если файл не перемещается (или, в лучшем случае, перемещается, но остается временный файл)?
На http://www.hostforum.ru/ не писали? Может быть, если перевести этот вопрос из приватной переписки в публичное обсуждение, так у саппорта будет мотив решить проблему?
Саппорт предложил мне следующее решение проблемы: в файле includes/file.inc перед строкой if (!move_uploaded_file($_FILES["files"]["tmp_name"][$source], $file->filepath)) {
вставить строку error_reporting('E_ALL ^ E_NOTICE');
Спасибо, конечно, саппорту за более-менее пригодное решение. Изображение прикрепляется, хотя и с огрехами. В частности, остается заблокированным временный файл в /tmp размером 282 байта. И пользователю выдается сообщение типа "Выбранный файл /pub/home/aquatica/tmp/fileJhtBAh не удается скопировать."
(аналогично и при удалении файлов).
Тем не менее, предложенное решение, конечно, довольно странное. Во-первых, на других хостингах по всему миру модуль image и функция move_uploaded_file прекрасно работают безо всяких "костылей" (и раньше на Валуе тоже работали). Мне хотелось бы добиться нормальной работы от хостинга.
Во-вторых, насколько я понимаю, директива error_reporting('E_ALL ^ E_NOTICE'); управляет уровнем контроля за ошибками (показывать все, кроме извещений), т.е. будут ли выводиться сообщения об ошибках. Но сами ошибки-то она не исправляет? Неудаленные временные файлы - тому подтверждение.
Еще вопросы возникают. Нужно ли после использования move_uploaded_file устанавливать исходный уровень контроля ошибок? Ну и что, теперь везде, где встречаются move_uploaded_file и подобные функции, хачить код?
Ответ саппорта про сообщения (warnings) о невозможности переместить или скопировать файл: "как выяснилось, этот warning каким-то образом попадает перед header'ом, возращаемым скриптом и сервер не может такие хэдеры разобрать. Возникает это именно на Друпале, именно в модуле image".
Добавлю - "и именно на Valuehost"
Продолжение банкета - завтра. Просили снова поднять вопрос и обещали разобраться.
Вчера ковырял загрузку файлов - интересный для меня момент выяснился, оказывается, что файл копируется 2жды!
первый раз из временного каталога системы во временный каталог друпала (у меня они не совпадают), а потом уже попадает в положенное ему местов files - может в этом беда, что промежуточный каталог не имеет нужных прав!
УРАААААААААААААА. ПОБЕДА!!!!!!!!!!!!!!!!
ЗАРАБОТАЛО!!!!!!!!!!!!!!!
Частичная. У меня, например, изображения добавляются, но при этом появляются сообщения типа "Выбранный файл /pub/home/my_login/tmp/fileWwRT3J не удается скопировать." Временные файлы перестали появляться в /tmp при добавлении, но при удалении появляются аж по три штуки.
Можно, конечно, выключить в настройках Drupal выдачу извещений на экран (только в логи). Но это все же непорядок.
Еще раз проверю. Но когда пробовал сообщения не появлялись.
На вопрос, что же все таки было изменено. Получил ответ:
"Не буду вдаваться в технические тонкости, могу сказать, что проблема была в специфике принципов построения пользовательских аккаунтов, были внесены изменения в код php."
А у меня картинки качаются нормально, зато 502 получаю пр ипопытке голосования в опросе (модуль Poll).
Хосетр - валухост. Наверное, и этот модуль "глючный"
Рад что у вас решилась, а остальным что делать?