apache - usuario - permisos var www html ubuntu
Apache 13 permiso denegado en el directorio de inicio del usuario (9)
El sitio web de mi amigo funcionaba bien hasta que movió la raíz del documento de /var/www/xxx a /home/user/xxx .
Apache otorga 13 mensajes de error denegación de permiso cuando intentamos acceder al sitio a través de un navegador web.
El sitio está configurado como un directorio virtual. Todas las configuraciones de Apache no se modificaron (a excepción del cambio de directorio) .
Intentamos chmod 777 /home/user/xxx , chown apache / home / user / xxx. Pero no funcionaron.
¿Hay algún tipo de característica de seguridad establecida en los directorios de inicio del usuario? El SO del servidor es CentOS (GoDdydy VPS).
¡Cualquier ayuda es apreciada!
¡Gracias!
¿Ha cambiado los permisos en los archivos individuales y solo en el directorio?
chmod -R 777 /home/user/xxx
¿No puedes configurar el Loglevel en httpd.conf para depurar? (Estoy usando FreeBSD)
ee usr / local / etc / apache22 / httpd.conf
cambiar nivel de registro:
''LogLevel: controla la cantidad de mensajes registrados en error_log. Los valores posibles incluyen: depuración, información, aviso, advertir, error, crítico, alerta, emerg. ''
Intente cambiar para depurar y volver a verificar el registro de errores después de eso.
El registro de errores de Apache explicará por qué le niegan un permiso. Además, serverfault.com es un foro mejor para una pregunta como esta.
Si el registro de errores simplemente dice "permiso denegado", su al usuario que el servidor web está ejecutando como y trata de leer desde el archivo en cuestión. Así por ejemplo:
sudo -s
su - nobody
cd /
cd /home
cd user
cd xxx
cat index.html
Vea si uno de esos le da el error de "permiso denegado".
Error:
[error] [client 127.0.0.1] (13)Permission denied: Could not open password file: /home/XXX/svn/svn_password
Información:
##SELinux Security Context File Labels #httpd_sys_content_t The type used by regular static web pages with .html and .htm extensions. #httpd_sys_script_ro_t Required for CGI scripts to read files and directories. #httpd_sys_script_ra_t Same as the httpd_sys_script_ro_t type but also allows appending data to files by the CGI script. #httpd_sys_script_rw_t Files with this type may be changed by a CGI script in any way, including deletion. #httpd_sys_script_exec_t The type required for the execution of CGI scripts
Solución:
[root@localhost]# perror 13 OS error code 13: Permission denied [root@localhost]# chown apache.apache /home/XXX/svn/ -R [root@localhost]# semanage fcontext -a -t httpd_sys_script_rw_t "/home/XXX/svn(/.*)?" [root@localhost]# restorecon -R -v /home/XXX/svn/ [root@localhost]# restorecon reset /home/XXX/svn/ context [root@localhost]# ls -dZ /home/XXX/svn/ drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 /home/XXX/svn/ [root@localhost]# ls -dZ /home/XXX/svn/svn_password -rwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 /home/XXX/svn/svn_password [root@localhost]#
Estoy usando CentOS 5.5 y para mí fue SElinux jugando con eso, me olvidé de verificarlo. puede desactivarlo temporalmente haciendo como root
echo 0 > /selinux/enforce
Espero que ayude a alguien
No estoy seguro si lo ha arreglado, pero en su httpd.conf
Verifique su configuración de usuario / grupo. Por lo general, se establecerá en
Usuario www Grupo www
Si es así, cámbialo a tu nombre / grupo
Usuario Greg group staff
Podría ser SELinux. Verifique el archivo de registro apropiado (/ var / log / messages? - hace un tiempo desde que utilicé un derivado de RedHat) para ver si eso está bloqueando el acceso.
Resulta que ... también tuvimos que chmod 755 el directorio padre, usuario, además de xxx.
Selinux es la causa de ese problema .....
TException: Error: TSocket: No se pudo conectar a localhost: 9160 (Permiso denegado [13]) Para resolverlo, debe cambiar un valor booleano de SELinux (que persistirá automáticamente durante los reinicios). Es posible que también desee reiniciar httpd para restablecer el trabajador proxy, aunque esto no es estrictamente necesario.
setsebool -P httpd_can_network_connect 1
o
(13) Permiso denegado
El error 13 indica un problema de permisos del sistema de archivos. Es decir, a Apache se le denegó el acceso a un archivo o directorio debido a permisos incorrectos. En general, no implica un problema en los archivos de configuración de Apache.
Para servir archivos, Apache debe tener el permiso apropiado otorgado por el sistema operativo para acceder a esos archivos. En particular, el Usuario o Grupo especificado en httpd.conf debe poder leer todos los archivos que se servirán y buscar en el directorio que contiene esos archivos, junto con todos los directorios principales hasta la raíz del sistema de archivos.
Los permisos típicos en un sistema tipo Unix para recursos que no son propiedad del Usuario o Grupo especificado en httpd.conf serían 644 -rw-r-r-- para archivos ordinarios y 755 drwxr-xrx para directorios o scripts CGI. También es posible que deba comprobar los permisos ampliados (como los permisos de SELinux) en los sistemas operativos que los admiten.
Un ejemplo
Supongamos que recibió el error Permiso denegado al acceder al archivo /usr/local/apache2/htdocs/foo/bar.html en un sistema tipo Unix.
Primero compruebe los permisos existentes en el archivo:
cd / usr / local / apache2 / htdocs / foo ls -l bar.htm
Solucionarlos si es necesario:
chmod 644 bar.html
Luego haga lo mismo para el directorio y cada directorio principal (/ usr / local / apache2 / htdocs / foo, / usr / local / apache2 / htdocs, / usr / local / apache2, / usr / local, / usr):
ls -la chmod + x. discos compactos ..
repetir hasta la raíz
En algunos sistemas, el nombre de la utilidadi se puede usar para ayudar a encontrar problemas de permisos al enumerar los permisos a lo largo de cada componente de la ruta:
namei -m /usr/local/apache2/htdocs/foo/bar.html
Si todos los permisos estándar son correctos y aún obtiene un error de Permiso denegado, debe verificar los permisos extendidos. Por ejemplo, puede usar el comando setenforce 0 para desactivar SELinux y verificar si el problema desaparece. Si es así, ls -alZ se puede usar para ver los permisos de SELinux y chcon para corregirlos.
En casos poco frecuentes, esto puede deberse a otros problemas, como un problema de permisos de archivos en otro lugar de su archivo apache2.conf. Por ejemplo, una directiva WSGIScriptAlias que no se correlaciona con un archivo real. El mensaje de error puede no ser exacto sobre qué archivo no se puede leer.
NO configure archivos o directorios en el modo 777, incluso "solo para probar", incluso si "es solo un servidor de prueba". El propósito de un servidor de prueba es hacer las cosas bien en un entorno seguro, no salirse con la suya al hacerlo mal. Todo lo que le dirá es si el problema es con los archivos que realmente existen.