move_uploaded_file дает ошибку при открытии потока: Permission denied error

Я продолжаю получать эту ошибку при попытке настроить каталог загрузки с Apache 2.2 и PHP 5.3 на CentOS.

В php.ini:

upload_tmp_dir = /var/www/html/mysite/tmp_file_upload/

В httpd.conf:

Directory /var/www/html/mysite/tmp_file_upload/>
    Options  -Indexes
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>
<Directory /var/www/html/mysite/images/>
                Options -Indexes
</Directory>

Разрешения каталога CentOS:

drwxrwxr-x 2 root root 4096 Nov 11 10:01 images
drwxr-xr-x 2 root root 4096 Nov 12 04:54 tmp_file_upload

Независимо от того, что я делаю, я все время получаю эту ошибку от PHP, когда загружаю файл:

Предупреждение: move_uploaded_file (images / robot.jpg): не удалось открыть поток: в /var/www/html/mysite/process.php в строке 78 отказано в доступе

Предупреждение: move_uploaded_file (): невозможно переместить '/ tmp / phpsKD2Qm' в 'images / robot.jpg' в /var/www/html/mysite/process.php в строке 78

Как видите, он никогда не брал конфигурацию из файла php.ini в отношении файла загрузки.

Что я здесь делаю не так?


person user63898    schedule 12.11.2011    source источник
comment
775? Возможно, ваш сервер работает как никто. Только root может писать в этом случае (ваши права доступа к изображениям) ...   -  person Konrad Borowski    schedule 12.11.2011
comment
что это значит ? как я могу это изменить?   -  person user63898    schedule 12.11.2011
comment
Помните, что ВСЕ родительские каталоги также должны иметь соответствующие разрешения.   -  person Sridhar Sarnobat    schedule 19.09.2017


Ответы (14)


Это потому, что images и tmp_file_upload доступны для записи только пользователю root. Чтобы загрузка работала, нам нужно сделать владельца этих папок таким же, как и владельца процесса httpd, ИЛИ сделать их глобально доступными для записи (плохая практика).

  1. Проверьте владельца процесса apache: $ps aux | grep httpd. Первый столбец будет владельцем, обычно это будет nobody
  2. Измените владельца images и tmp_file_upload, чтобы он стал nobody или другим владельцем, которого вы нашли на шаге 1.

    $sudo chown nobody /var/www/html/mysite/images/
    
    $sudo chown nobody /var/www/html/mysite/tmp_file_upload/
    
  3. Chmod images и tmp_file_upload теперь могут быть доступны для записи владельцем, если это необходимо [Кажется, у вас это уже есть]. Упоминается в ответе @Dmitry Teplyakov.

    $ sudo chmod -R 0755 /var/www/html/mysite/images/
    
    $ sudo chmod -R 0755 /var/www/html/mysite/tmp_file_upload/
    
  4. Подробнее о причинах такого поведения см. В руководстве http://php.net/manual/en/ini.core.php#ini.upload-tmp-dir, обратите внимание, что здесь также говорится о директиве open_basedir.

person Laith Shadeed    schedule 12.11.2011
comment
Спасибо: нашим старым владельцем был демон, теперь это apache - person zzapper; 18.06.2013
comment
Это исправление применимо к ситуациям, когда вы могли изменить тип php серверов с fast_CGI, CGI на Apache_mod, поскольку plesk и т. Д. Может продолжить работу с разрешениями исходного пользователя, а не с apache. Это устранило мои проблемы. - person elliotrock; 16.10.2014
comment
У меня такая же ошибка, но и процесс, и папки принадлежат jacob (я, поскольку это моя локальная машина), а во всех папках есть 755 или 775. - person limeandcoconut; 08.02.2015
comment
Мне пришлось перезапустить мой процесс apache sudo service httpd restart после изменения разрешений. Тогда это сработало :) Вместо смены владельца chown я добавил свой процесс apache в группу 'www' и добавил эти каталоги в ту же группу 'www' через chgrp - person Ali Saeed; 09.04.2015

Вы также можете запустить этот скрипт, чтобы узнать владельца процесса Apache:

<?php echo exec('whoami'); ?>

А затем измените владельца целевого каталога на того, что у вас есть. Используйте команду:

chown user destination_dir

А затем используйте команду

chmod 755 destination_dir

для изменения разрешения каталога назначения.

person twlkyao    schedule 18.11.2013
comment
Спасибо, у меня работает. Сначала я использовал метод Laith Shadeed, но не получаю того же результата, набирая ps aux | grep httpd и <?php echo exec('whoami'); ?>. Кто-нибудь знает почему? - person kukinsula; 17.06.2014
comment
ps aux | grep https не возвращает имя владельца веб-сервера. Это делает: ps aux | grep -E '[a] pache | [h] ttpd | [_] www | [w] ww-data | [n] ginx' | grep -v root | голова -1 | вырезать -d \ -f1 Fron Symfony doc. - person David Jacquel; 22.07.2014
comment
Обратите внимание, что в приведенной выше команде должно быть два пробела между -d \ и -f1. Если вы скопируете и вставите как есть, вы можете получить сообщение об ошибке, например, cut: bad delimiter. - person Beejor; 05.04.2015
comment
плюс 1 для exec('whoami'). Сэкономил мне еще 30 минут. ел пользователя ubuntu - person Deval Khandelwal; 14.04.2015
comment
это должно быть www-data? обычно - person maxisme; 27.04.2015
comment
Намного лучший ответ, чем принятый в настоящее время. exec ('whoami'); было гораздо лучшим решением для поиска пользователя, от имени которого работает apache, чем принятый в настоящее время метод проверки процесса apache. - person BruceJohnJennerLawso; 27.02.2018
comment
Цените это, exec('whoami') спас меня! - person Suge; 20.03.2019

Это сработало для меня.

sudo adduser <username> www-data
sudo chown -R www-data:www-data /var/www
sudo chmod -R g+rwX /var/www

Затем выйдите из системы или перезагрузитесь.

Если SELinux жалуется, попробуйте следующее

sudo semanage fcontext -a -t httpd_sys_rw_content_t '/var/www(/.*)?'
sudo restorecon -Rv '/var/www(/.*)?'
person Junius L.    schedule 27.04.2017
comment
спас мою жизнь :) .. я использую GIT post-recive hook для развертывания моей сети, и каждый раз, когда я развертываю, я получаю его ошибку с отказом в разрешении, добавление пользователя git в www-data исправлено :) спасибо - person Zalaboza; 08.08.2017
comment
Это лучший ответ. - person saviour123; 08.11.2017
comment
Не волнуйтесь! Ваш ответ самый лучший в наших сердцах. Вы только что спасли мне жизнь и я не знаю, как сказать спасибо !!!! - person Abdulaziz Al Jumaia; 16.07.2021

Если у вас Mac OS X, перейдите в корень файла или папку вашего веб-сайта.

Затем щелкните его правой кнопкой мыши, перейдите для получения информации, перейдите в самый низ (Совместное использование и разрешения), откройте его, измените все только для чтения на чтение и запись. Обязательно откройте замок, перейдите к значку настройки и выберите Применить к вложенным элементам ...

person hawkar ITstudent    schedule 15.03.2016
comment
Почему вы комментируете Mac OS, когда его вопрос касается системы Linux? - person Kmeixner; 15.03.2016
comment
Привет, Хокар, спасибо за ответ. Я использую Mac, и ваш ответ решил мою проблему. Большое спасибо. - person Sanjay Sharma; 28.09.2016
comment
Люблю этот ответ - person Alexey Sh.; 29.12.2017
comment
@Kmeixner этот вопрос о Linux, но у меня была точно такая же проблема на моем OSX. Спасибо за этот комментарий, он сработал для меня после того, как я изменил параметры записи в папке /private/var/tmp на моем Mac. - person Salam; 02.05.2018
comment
Это более старый пост, но это именно то, что мне нужно было сделать. Благодарность - person TheRobQ; 05.09.2018
comment
Спас меня от самоубийства второй раз :-P - person Abdul Saleem; 09.02.2019

Я хотел добавить это к предыдущим предложениям. Если вы используете версию Linux, в которой включен SELinux, вам также следует выполнить это в как ад:

chcon -R --type httpd_sys_rw_content_t /path/to/your/directory

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

person Chris    schedule 14.05.2017
comment
restorecon -R -v /path/to/your/directory, вероятно, тоже нужно будет включить в это позже. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/ - person AbsoluteƵERØ; 10.07.2017
comment
вполне может быть правдой, но я был в предположении, что chcon изменил контекст, т.е. он был просто изменен. то, что вы смотрите, сначала использует semanage fcontext, который помещает его в некоторый файл настроек file_contexts.local, однако он никогда не меняет контекст. - person Chris; 06.09.2017
comment
@ Крис, спасибо, чувак. Это решило мою проблему. Не могли бы вы пролить свет на этот вопрос? Что на самом деле делает эта команда? Я просмотрел страницы руководства и даже информацию о chcon и не нашел значения введенного вами типа. Я здесь немного запутался. - person joker; 09.06.2019
comment
он делает каталог или файлы доступными для чтения веб-сервером (httpd) ... я, честно говоря, не хочу и, вероятно, не могу объяснить selinux, поскольку я сам едва ли в этом разбираюсь ... см. nsa.gov/what-we-do/research/selinux/documentation и access.redhat.com/documentation/en-us/red_hat_enterprise_linux/ - person Chris; 17.06.2019

Изменить разрешения для этой папки

# chmod -R 0755 /var/www/html/mysite/images/

person Dmitry Teplyakov    schedule 12.11.2011
comment
теперь это похоже на: drwxrwxr-x 2 root root 4096 11 ноября 10:01 изображения также включены: drwxrwxr-x 2 root root 4096 12 ноября 04:54 tmp_file_upload, но все та же ошибка - person user63898; 12.11.2011

Попробуй это:

  1. открыть / etc / apache2 / envvars

    sudo gedit /etc/apache2/envvars
    
  2. замените www-data своим your_username

    "export APACHE_RUN_USER=www-data" 
    

    заменить

    export APACHE_RUN_USER='your_username' 
    
person redrider    schedule 14.07.2015

Я столкнулся с этой связанной проблемой даже после того, как уже успешно запустил composer. Я обновил композитор, и при запуске composer install или php composer.phar install получил:

... не удалось открыть поток: в доступе отказано ...

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

В моей установке в OS X файл кеша находится в /Users/[USER]/.composer/cache, и у меня возникли проблемы, потому что файл кеша принадлежал пользователю root. Рекурсивная смена владельца '.composer' моему пользователю решила проблему.

Вот что я сделал:

sudo chown -R [USER] cache

Затем я снова запустил установку композитора и вуаля!

person abaumer    schedule 14.01.2014

Эта проблема возникает, когда пользователь apache (www-data) не имеет разрешения на запись в папку. Чтобы решить эту проблему, вам нужно поместить пользователя в группу www-data.

Я только что сделал это:

Выполните этот php-код <?php echo exec('whoami'); ?>, чтобы обнаружить пользователя, которого использует apache. После выполните команды в терминале:

user@machine:/# cd /var/www/html

user@machine:/var/www/html# ls -l

Он вернет что-то вроде этого:

total of files

drwxr-xr-x 7 user group size date folder

Я сохранил пользователя, но изменил группу на www-data

chown -R user:www-data yourprojectfoldername

chmod 775 yourprojectfoldername
person Jefferson Romano    schedule 15.02.2016

Решение очень простое. Щелкните правой кнопкой мыши папку IMAGE (место назначения), перейдите к свойствам, щелкните вкладку разрешений и измените доступ других на Создание и удаление файлов.

person Basim    schedule 17.08.2017
comment
Самый быстрый способ, НО, только вы используете графический интерфейс для FTP (FileZilla, WinSCP) - person CLOUGH; 20.08.2018
comment
помогло спасибо @basim - person AndroidManifester; 28.06.2021

Просто измените разрешение tmp_file_upload на 755. Ниже приводится команда chmod -R 755 tmp_file_upload.

person Sarang    schedule 22.11.2012

Попробуй это

find /var/www/html/mysite/images/ -type f -print0 | xargs -0 chmod -v 664

person Simone    schedule 12.11.2011
comment
получение: chmod: операнд отсутствует после `664 ' - person user63898; 12.11.2011

Это происходит, если включен SELinux. Отключите это в /etc/selinux/config, установив SELINUX=disabled, и перезапустите сервер.

person Srihari Karanth    schedule 25.09.2020

Я пробовал все вышеперечисленные решения, но следующее решило мою проблему

chcon -R -t httpd_sys_rw_content_t your_file_directory
person Mithun Sarker Shuvro    schedule 13.12.2020