2009-08-04 22 views
38

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 13 permiso denegado en el directorio de inicio del usuario

Apache proporciona 13 mensajes de error de 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 (excepto para el 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).

¡Se agradece cualquier ayuda!

Gracias!

+3

debe ir en serverfault. –

+0

No sabía nada de eso hasta que lo mencionó =) Creo que lo intentaré. ¿Por qué conservan dos (tal vez más?) Sitios de todos modos? ¿No es mejor centralizar esas categorías? – Dave

+0

@Dave: stackoverflow.com es para preguntas de programación; serverfault.com es para preguntas de sysadmin/servidor; superuser.com es para los "usuarios avanzados" generales y otras preguntas relacionadas con la computadora. Ayuda a las personas a centrarse en sus áreas de especialización, supongo. – Josh

Respuesta

84

Resulta que también tuvimos que chmod 755 el directorio padre, usuario, además de xxx.

+2

GRACIAS <3 (límite de 15 caracteres ... bla) –

+0

También encontré este problema, había seguido los pasos aquí: http://serverfault.com/questions/ 124800/how-to-setup-linux-permissions-for-the-www-folder y finalmente había perdido el bit de ejecución para el directorio de otros que me estaba negando el acceso a la carpeta, ejecuté 'sudo chmod o + x/var/www 'para el directorio para que apache pueda leer – shaunhusain

+0

Me golpeó la cabeza durante dos horas, nunca pensé en verificar los permisos en la casa del usuario. Gracias Dave! –

-2

¿Ha cambiado los permisos en los archivos individuales, así como solo en el directorio?

chmod -R 777 /home/user/xxx 
+2

Nunca debe hacer chmod 777 en archivos de acceso público – 6bytes

3

El registro de errores de Apache explicará por qué obtiene un permiso denegado. 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 del archivo en cuestión. Entonces, por ejemplo:

sudo -s 
su - nobody 
cd/
cd /home 
cd user 
cd xxx 
cat index.html 

Vea si alguno de ellos le da el error de "permiso denegado".

+0

Sí, revisamos el registro de errores. Todo lo que tenía era (13) permiso denegado. ¿Hay algún parámetro que podamos configurar para habilitar más salidas de depuración? – Dave

2

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.

+0

Gracias por su ayuda. Intenté buscar en/var/log/messages; hay un montón de ellos: mensajes, messages.1.gz, messages.2.gz, ... hasta messages.14.gz./var/log/messages está vacío; también lo son los otros después de descomprimirlos ... – Dave

3

¿No puedes configurar el Loglevel en httpd.conf para depurar? (Estoy usando FreeBSD)

ee/apache22/httpd.conf

cambio de nivel de registro/local/etc usr:

'Loglevel: controlar el número de mensajes registrados en el error_log. Los valores posibles incluyen: depuración, información, aviso, advertir, error, crítico, alerta, emerg. '

Intente cambiar para depurar y volver a comprobar el registro de errores después de eso.

+0

Gracias, ahora el registro de errores es: (13) Permiso denegado: /home/user/.htaccess pcfg_openfile: no se puede verificar el archivo htaccess, asegúrese de que sea legible – Dave

+0

Traté de buscar soluciones específicas para ese error. Pero, la mayoría de ellos implican archivos chmod'ing a los permisos correctos (que ya he hecho). Algunos de ellos dicen que implica la extensión de la página principal. Pero, nunca lo usamos para empezar ... – Dave

6

No está seguro si he arreglado pero en su httpd.conf

Compruebe la configuración de usuario/grupo.Por lo general, se establecerá en

www usuario www Grupo

Si es así cambiarlo a su nombre/grupo

usuario Greg grupo de personal

+0

Esto realmente solucionó el problema, estos errores nunca desaparecen tan fácilmente. Esto es asombroso – pal4life

+0

Para apache2 en sistemas Ubuntu 12.04 encontré los documentos indicados '# Estos deben establecerse en/etc/apache2/envvars' – CrandellWS

37

im utilizando CentOS 5.5 y para mí fue SElinux jugando con eso, me olvidé de echarle un vistazo. puede deshabilitar temporalmente por hacer como root

echo 0 > /selinux/enforce 

espero que ayude a alguien

+7

Esto sin duda ayudaría a aquellos que no estén interesados ​​en selinux en absoluto. Recomiendo simplemente cambiar un poco la configuración de Selinux. Por ejemplo, ejecutar lo siguiente lo hará para que los usuarios puedan configurar un host virtual para que se ejecute en su directorio principal: setsebool -P httpd_enable_homedirs 1 – shaune

+0

usted es genio ...... kek .... –

+0

esto es mágico ! gracias tan papilla – Spartan

11

selinux es causa de ese problema .....

TException: Error: TSocket: No se pudo conectar a localhost: 9160 (Permiso denegado [13]) Para resolverlo, debe cambiar un valor booleano SELinux (que se mantendrá 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

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 serán servidos 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 unix para recursos que no son propiedad del Usuario o Grupo especificado en httpd.conf serían 644 -rw-r-r-- para archivos comunes y 755 drwxr-xrx para directorios o CGI guiones. También es posible que deba comprobar los permisos ampliados (como los permisos de SELinux) en los sistemas operativos que los admiten.

Un ejemplo

Digamos que ha recibido el error Permiso denegado cuando se accede a la /usr/local/apache2/htdocs/foo/bar.html archivo en un sistema de tipo Unix.

primer lugar, compruebe los permisos existentes en el archivo:

cd/usr/local/apache2/htdocs/foo ls -l bar.htm

Corregir si es necesario:

chmod 644 bar.html

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. cd ..

repita hasta la raíz

En algunos sistemas, la namei utilidad se puede utilizar para ayudar a encontrar problemas de permisos haciendo una lista de 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 excepcionales, 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.

+0

Gracias, httpd_can_network_connect era lo que necesitaba para habilitar SoapClient en centos – zpon

0

error:

 
[error] [client 127.0.0.1] (13)Permission denied: Could not open password file: /home/XXX/svn/svn_password 

Info:

 
##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:

 
[[email protected]]# perror 13 
OS error code 13: Permission denied 
[[email protected]]# chown apache.apache /home/XXX/svn/ -R 
[[email protected]]# semanage fcontext -a -t httpd_sys_script_rw_t "/home/XXX/svn(/.*)?" 
[[email protected]]# restorecon -R -v /home/XXX/svn/ 
[[email protected]]# restorecon reset /home/XXX/svn/ context 
[[email protected]]# ls -dZ /home/XXX/svn/ 
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 /home/XXX/svn/ 
[[email protected]]# 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 
[[email protected]]# 

Cuestiones relacionadas