Измените конфигурацию авторизации:
<Directory /home/remix/>
#...
Order allow,deny
Allow from all
</Directory>
... на версию того же Apache 2.4.
<Directory /home/remix/>
#...
Require all granted
</Directory>
Просмотрите ] обзор обновления для получения информации о других изменениях, которые могут вам потребоваться - и имейте в виду, что большинство примеров конфигурации и помощи, которые вы найдете там в Google (а также на этом сайте), относятся к 2.2.
Другой простой (но игривый глюк), который мог бы вызвать эту проблему для людей, - когда пользовательские каталоги не находятся в / домой /* Но где-то в другом месте например,/nethome /*
, предоставленный userdir.conf содержит что-то вроде этого: (но с Userdir: отключенный)
$ cat /etc/httpd/conf.d/userdir.conf
<IfModule mod_userdir.c>
UserDir enabled
UserDir public_html
</IfModule>
<Directory "/home/*/public_html">
AllowOverride FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Require method GET POST OPTIONS
</Directory>
спецификация Каталога принимает ~user ==/home/user. Просто измените или добавьте спецификацию Каталога для того, где пользовательские корневые каталоги на самом деле.
Симпатичный из очевидных, но взял меня некоторое время для выяснения!!:-P ПОНЯТНОЕ ДЕЛО!
, например, ~user ==/nethome/user
<Directory "/nethome/*/public_html">
AllowOverride All
Options MultiViews Indexes Includes FollowSymLinks
Require all granted
</Directory>
См. также более открытую авторизацию на том Каталоге обычно.
Проверьте права доступа к каталогу. Могу поспорить, что он настроен так, чтобы запрещать доступ кому-либо, кроме вас самих, например:
$ ls -ld /home/remix
drwx------ 92 remix remix 4096 Aug 17 22:59 /home/remix
Если вы видите drwx ------
точно, то это так. Исправьте это, запустив:
chmod a+x /home/remix
Убедитесь, что у пользователя, который запускает службу httpd
, есть доступ к этим каталогам.
«клиент отклонен конфигурацией сервера» означает, что сам сервер Linux запрещает доступ к файлу, а не Apache.
Если предоставление доступа через изменение разрешений / владения / членства в группе не решает проблема, причиной маршрута может быть SELinux, запрещающий доступ к любой папке, которая не имеет соответствующего контекста SE Linux, как объяснено в «Перемещение Apache DocumentRoot под Selinux» .
setenforce 0
делает файл доступным setenforce 0
снова делает файл недоступным Затем для убедитесь, что доступ запрещен SELinux независимо от прав доступа к файлу.
В моем случае я добавил приложение (phpMemcacheAdmin), но не позаботился о добавлении монтировок в стек развертывания, поэтому их даже не было (материал кубернетов) при запуске. Я потратил час на то, чтобы удалить лишние косые черты и изменить разрешения, и, наконец, обнаружил, что их даже нет.
Если вы пытаетесь выполнить развертывание в k8s, дважды проверьте, что они у вас есть (если вы используете hostPath):
...
volumeMounts:
- mountPath: /opt/phpMemcacheAdmin
name: memcached-admin
...
- hostPath:
path: /...../opt/phpMemcacheAdmin
type: ""
name: memcached-admin