Каталог временных файлов не указан в параметрах php

Обновлено: 21.11.2024

Когда я пытаюсь восстановить курс в только что установленном Moodle 3.3.1, я получаю следующее сообщение об ошибке:

"В PHP отсутствует временная папка"

Я использую сервер Linux с PHP 7.0.21 и Moodle 3.3.1+ (сборка: 20170714).

После предыдущих обсуждений Moodle я попытался настроить php.ini так, чтобы он указывал на созданную мной папку /tmp. Не повезло.

Затем в файле php.ini сервера я раскомментировал upload_tmp_dir и установил его в папку /tmp. Тоже не повезло. Даже после изменения разрешений на tmp. Я использовал php.ini сервера, указанный в пути в php.info Moodle.

Наш старый сервер, работающий под управлением PHP 5.6, продолжает без проблем восстанавливать те же резервные копии на Moodle 3.1.3, поэтому файлы резервных копий в порядке.

Здесь может быть путь к решению: документ Moodle по PHP говорит: «Временная папка должна быть определена и доступна для записи пользователем вашего веб-сервера». Может ли кто-нибудь дать конкретные шаги о том, как это сделать?

Спасибо за любую вашу информацию.

Moodle должен использовать собственный временный каталог для восстановления резервных копий.

Проверьте права собственности/права доступа к файлу moodledata/temp/. Там при восстановлении курса или резервном копировании курса moodle должен использовать каталог с именем «backup». Пользователь веб-службы должен иметь возможность создать каталог, если он отсутствует. Если это невозможно, то что-то не так с правами собственности/разрешениями. Но создайте «резервную копию» самостоятельно и предоставьте ей очень либеральные разрешения — глобальное чтение/запись разрешено в moodledata.

Только что проверил 3.3.1 - обновил буквально на днях. Резервное копирование PHP 7.0.10 (CentOS 7) работает и использовало moodledata/temp/backup/ для создания резервной копии. И восстановил ход. восстановить работы. и он также использовал каталог moodledata/temp/backup/.

'дух обмена', Кен

У Moodledata есть временный каталог с каталогом резервных копий внутри него, с обоими разрешениями, установленными на 777, так что оба они кажутся правильными.

Проблема относится и к другим загрузкам, выполненным в Moodle, например к загрузке логотипа в тему Essential. Я без труда могу загрузить через cPanel, но это не помогает с восстановлением курса.

Отладка обеспечивает следующее:

  • Временная папка должна быть определена и доступна для записи пользователем вашего веб-сервера

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

Когда вы устанавливали Moodle 3.3.1, в файле php.ini Moodle была строка, определяющая таким образом временную папку?

Или эта строка указывает на необходимость проверки настроек php.ini сервера?

Ну, вы упомянули несколько вещей, которые могут быть причиной ваших проблем.

В автономной, не размещенной удаленно, совместно используемой или выделенной стоковой версии Ubuntu 16.04 или CentOS 6/7 после установки PHP файл php.ini в /etc/php.ini может иметь настройку для того, какой временный каталог использовать при загрузка. Для систем я кратко описал временный каталог /tmp/. Это системы, с которыми я работаю — у них нет cPanel. не размещайте там, где размещаете.

Однако ваша система не похожа на "стандартную" . была упомянута cpanel. cPanel не делает версию для использования на «стандартном» сервере Linux, а скорее для нескольких пользователей (общая система) или, если это VPS, «пользовательская тюрьма». не использует /var/www/html в качестве корня документа для службы apache 'home'.

В пользовательском интерфейсе администратора Moodle, на сервере, в информации о PHP. обычно показывает все настройки для PHP (даже показывает путь к файлу php.ini, который он читает, включая пользователя, под которым работает служба apache (может быть логин вашей учетной записи). Он также читает из php.ini переменные, такие как временный каталог.

Теперь вы сказали, что использовали cPanel для загрузки файлов . изображения для темы Essentials? другие файлы? Если вы сделали это с репозиторием файловой системы . расположенный в файле moodledata/repository/[somedirectoryyoucreated], ошибка может относиться к тому каталогу репозитория, который вы создали.

Вы загружаете резервные копии в файл moodledata/repository/[somedirectoryyoucreated]?

Возвращает путь к каталогу, в котором PHP по умолчанию хранит временные файлы.

Параметры

Эта функция не имеет параметров.

Возвращаемые значения

Возвращает путь к временному каталогу.

Примеры

// Создаем временный файл в каталоге временных
// файлов с помощью sys_get_temp_dir()
$temp_file = tempnam ( sys_get_temp_dir (), 'Tux' );

Приведенный выше пример выведет что-то похожее на:

См. также

  • tmpfile() — создает временный файл
  • tempnam() — создать файл с уникальным именем

Примечания, внесенные пользователями 12 примечаний

При работе в системе Linux, где systemd имеет PrivateTmp=true (это значение по умолчанию в CentOS 7 и, возможно, других более новых дистрибутивах), эта функция просто вернет "/tmp", а не истинный, гораздо более длинный, несколько динамический путь .

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

Эта функция не всегда добавляет завершающую косую черту. Такое поведение неодинаково в разных системах, поэтому вам следует следить за ним.

Это не задокументировано, но эта функция не отправляет путь с пробелами в конце, на самом деле она удаляет косую черту, если она существует.

Очень полезно обратить внимание на Linux:

Если вы запускаете PHP из командной строки, вы можете использовать переменную среды: TMPDIR — чтобы изменить местоположение, не касаясь php.ini. - Это должно работать на большинстве версий PHP.

Пример файла: test.php
echo sys_get_temp_dir() . PHP_EOL;
?>

А потом бегом:

php test.php
/tmp

TMPDIR=/custom/location php test.php
/custom/location

следует отметить, что возвращаемое значение sys_get_temp_dir() может быть установлено с помощью ini-директивы 'sys_temp_dir' глобально, а также для каждого каталога с помощью
php_admin_value sys_temp_dir /path/to/tmp

Эта функция не учитывает специфичные для виртуального хоста изменения временного пути и/или open_basedir:

php_admin_value open_basedir /home/user
php_admin_value upload_tmp_dir /home/user/tmp
php_admin_value session.save_path /home/user/tmp

В этой конфигурации он по-прежнему возвращает /tmp

Для создания путей посредством конкатенации важно знать, что sys_get_temp_dir не включает разделитель пути в конце.

Итак, sys_get_temp_dir() по умолчанию вернет значение вашего временного каталога:

Если вы попытались соединить другое временное имя каталога и использовать следующее:

Это на самом деле попытается сгенерировать:
/tmpsome_dir

Это, скорее всего, приведет к ошибке разрешения, если только вы не запускаете php-скрипт от имени суперпользователя.

Вместо этого вы могли бы сделать:
mkdir( sys_get_temp_dir() . DIRECTORY_SEPARATOR. 'some_dir' );

что создаст:
/tmp/some_dir

Я не знаю, есть ли в Windows или других платформах разделитель каталогов в конце. Поэтому, если вы пишете что-то более общее, вы можете проверить наличие разделителя пути в конце и, если его нет, добавить его.

Я работаю над загрузкой файлов через веб-страницу с индикатором выполнения, используя загрузчик файлов Valums. Почти все работает нормально, но я не могу изменить каталог tmp по умолчанию, в котором хранится файл во время загрузки.

Файлы следует хранить в каталоге /upload, а не в системном каталоге /tmp по умолчанию, поскольку /tmp монтируется на RAM-диске, размер которого ограничен 4 МБ, а пользователь будет загружать файлы размером около 10 МБ.

Я просмотрел множество веб-страниц, но ни одно решение не помогло. Я установил временный каталог в php.ini:

Я установил разрешения для каталога /upload, а apache является владельцем файла, поэтому PHP определенно может записывать этот каталог.

Я установил целевой путь в загрузчике файлов /upload , потому что я хочу, чтобы файлы после загрузки также сохранялись в этом каталоге. Конечным результатом является то, что небольшие файлы загружаются успешно, но файлы размером более 4 МБ не загружаются - единственная причина такого поведения, которая приходит мне на ум, заключается в том, что файлы сохраняются в / tmp во время загрузки. Чтобы быть уверенным, я проверил это с помощью sys_get_temp_dir(), и результат был /tmp, поэтому PHP игнорирует мою директиву php.ini или есть какой-то другой способ указать, где файлы сохраняются во время загрузки.

О, и последняя информация: open_basedir не установлен, поэтому доступ PHP к диску ограничен только правами доступа к файлу.

Нет глупых вопросов, есть глупые ответы :). Да, я делал это много раз, пытаясь решить проблему и пробуя разные решения.

Проверили ли вы, что php не установлен как мод cgi? (Из документа: Если указанный здесь каталог недоступен для записи, PHP возвращается к системному временному каталогу по умолчанию)

6 ответов 6

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

Проверьте upload_tmp_dir в php.ini.Это каталог, в котором PHP хранит временные файлы при загрузке.

Проверьте open_basedir в php.ini. Если он определен, он ограничивает права чтения/записи PHP на указанный путь и его подкаталоги. Убедитесь, что upload_tmp_dir находится внутри этого пути.

Проверьте post_max_size в php.ini. Если вы хотите загрузить файлы размером 20 Мбайт, попробуйте что-нибудь побольше, например post_max_size = 21M. Это определяет максимальный размер POST-сообщения, которое вы, вероятно, используете во время загрузки.

Проверьте upload_max_filesize в php.ini. Указывает самый большой файл, который можно загрузить.

Проверьте memory_limit в php.ini. Это максимальный объем памяти, который может потреблять скрипт. Совершенно очевидно, что он не может быть меньше размера загружаемого файла (честно говоря, я не совсем в этом уверен — возможно, PHP буферизируется при копировании временных файлов).

Проверьте, от имени какого пользователя работает php (см. здесь, как это сделать: Как проверить, от имени какого пользователя работает php? ). Я работал на разных дистрибутивах и серверах. Иногда это apache, но иногда это может быть root. В любом случае, убедитесь, что у этого пользователя есть права на чтение и запись во временном каталоге и каталоге, в который вы загружаете. Проверьте все каталоги в пути, если вы загружаете в подкаталог (например, /dir1/dir2/ - проверьте оба каталога: dir1 и dir2 .

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

У меня есть OwnCloud 8.2.2, развернутый на компьютере с Fedora 23. По умолчанию его /tmp является монтированием tmpfs, а это означает, что любая загрузка файла OwnCloud, размер которого превышает доступную системную оперативную память, завершится ошибкой, поскольку он использует /tmp в качестве временного каталога загрузки. Я пытался установить каталог загрузки на что-то другое с помощью параметра tempdirectory в config.php, но, похоже, это не дало эффекта. Все загрузки по-прежнему идут в /tmp.

Этапы воспроизведения

  1. Создайте каталог tmp в папке owncloud. Установите разрешения rw для пользователя apache.
  2. Установите 'tempdirectory' => '/var/www/html/owncloud/tmp' в config.php
  3. Загрузить файл с помощью веб-интерфейса или WebDav. Обратите внимание, что owncloud по-прежнему использует /tmp в качестве временного каталога для загрузки

Ожидаемое поведение

/var/www/html/owncloud/tmp следует использовать в качестве временного каталога загрузки вместо веб-интерфейса и WebDav

Реальное поведение

Загрузки идут в /tmp, а загрузка больших объемов в конечном итоге невозможна из-за нехватки места в ОЗУ.

Конфигурация сервера

Операционная система: Fedora 23

Веб-сервер: Apache/2.4.18

База данных: Maria DB 1:10.0.21-1.fc23

Версия PHP: PHP/5.6.17

Версия ownCloud: 8.2.2

Обновлено из более старой версии ownCloud или новой установки: обновлено с версии 8.1

Список активированных приложений:

Содержимое файла config/config.php:

Используете ли вы внешнее хранилище, если да, то какое: нет

Используете ли вы шифрование: нет

Используете ли вы внешний пользовательский интерфейс, если да, то какой: нет

Конфигурация клиента

Браузер: Chrome 48

Операционная система: Fedora 23

Журнал ошибок веб-сервера

журнал ownCloud (data/owncloud.log)

Журнал браузера

Текст был успешно обновлен, но возникли следующие ошибки:

1Fopresta прокомментировал 5 февраля 2016 г.

Привет, у меня такая же проблема.

Операционная система: Debian 8
Веб-сервер: Apache/2.4.10
База данных: MySQL 5.5.46
Версия PHP: PHP/7.0.2
Версия ownCloud: 8.2 .2
Обновлено из более старой версии ownCloud или новой установки: новая установка 8.2.2

PVince81 прокомментировал 15 февраля 2016 г.

поскольку он использует /tmp в качестве временного каталога для загрузки

Это не на 100% верно. В обычной ситуации без каких-либо внешних хранилищ файлы чанков хранятся в «data/$user/cache/», а файлы частей — непосредственно в хранилище при загрузке через Webdav.

Единственная ситуация, когда ownCloud будет явно использовать хранилище tmp, — это при загрузке/выгрузке в/из внешних хранилищ, которые не поддерживают потоковую передачу (или там, где потоковая передача не была реализована), и в этом случае он сначала создает файл в tmp. , затем вызывает API хранилища и сообщает ему загрузить этот файл. (пример: GDrive)

Есть еще две ситуации, когда PHP может использовать временное хранилище:

urbenlegend прокомментировал 17 февраля 2016 г.

У меня нет php-fpm. На самом деле пакет php-fpm даже не установлен. Я также использую обычную папку в каталоге owncloud для хранения данных. Однако WebDav по-прежнему использует /tmp.

PVince81 прокомментировал 17 февраля 2016 г.

@urbenlegend, можете ли вы опубликовать имена временных файлов, которые вы там видите? Может помочь узнать, какая часть Apache/PHP/ownCloud их генерирует.

urbenlegend прокомментировал 17 февраля 2016 г.

PVince81 прокомментировал 18 февраля 2016 г.

Это похоже на временный файл, который PHP создаст при загрузке через веб-интерфейс.

Была ли это загрузка через веб-интерфейс или через Webdav? Webdav не должен идти туда. Веб-интерфейс работает, потому что мы используем POST для загрузки.

Вы можете попробовать изменить значение "upload_tmp_dir" в файле php.ini.

Думая об этом, может быть, есть способ для ownCloud установить это значение программно, чтобы заставить PHP использовать настроенную временную папку.

urbenlegend прокомментировал 18 февраля 2016 г.

Это была загрузка WebDAV с использованием монтирования в Nautilus.

Я подумал об изменении upload_tmp_dir, но нет возможности установить его для каждого сайта отдельно. Это относится ко всему моему серверу Apache, на котором также размещаются два блога WordPress, и я не хочу менять для них каталог tmp.

PVince81 прокомментировал 9 марта 2016 г.

Можете ли вы изменить его на одном сайте, чтобы убедиться, что это действительно проблема?

Установив это значение для улучшения, можно проверить, можно ли заставить ownCloud установить это значение php.ini программно.

rullzer прокомментировал 10 марта 2016 г.

Из того, что я узнал, вы не можете сделать это из owncloud.

Похоже, это то, что вам нужно.

комментарий mmattel от 11 марта 2016 г.

Переопределить, где ownCloud хранит временные файлы. Полезно в ситуациях, когда системный временный каталог находится на виртуальном диске с ограниченным пространством или иным образом ограничен, или если используются внешние хранилища, не поддерживающие потоковую передачу.

Пользователь веб-сервера должен иметь доступ для записи в этот каталог. .

Мы должны принять формулировку в документации, чтобы сделать ее более понятной, и добавить информацию от @rullzer выше, чтобы завершить. Я выделил соответствующие фрагменты текста из @PVince81, чтобы подумать о жирном шрифте.

Читайте также: