nginx não lê montado / usr / share / nginx / html

0

Meta:

Estou usando um contêiner NGINX no qual eu montei um sistema de arquivos SSHFS remoto / usr / share / nginx / html , o objetivo é usar cada vez um novo contêiner nginx sem estado, mas com o mesmo conteúdo persistente.

Etapas realizadas:

- Certifique-se de que o servidor SSHFS esteja ativo e em execução.
-No container nginx (cliente sshfs) montei o sistema de arquivos sshfs remoto em / usr / share / nginx / html

/ # sshfs  [email protected]:/data /usr/share/nginx/html
[email protected]'s password:  / #

-A montagem parece bem:

/ # mount | grep sshfs

[email protected]:/data on /usr/share/nginx/html type fuse.sshfs
(rw,nosuid,nodev,relatime,user_id=0,group_id=0)  

/ # df -h
Filesystem                 Size  Used Avail Use% Mounted on  
rootfs                     886G  681G  161G  81% /  
none                       886G  681G  161G  81% /  
tmpfs                      7.9G     0  7.9G   0% /dev  
tmpfs                      7.9G     0  7.9G   0% /sys/fs/cgroup  
/dev/sda1                  886G  681G  161G  81% /gns3  
shm                         64M     0   64M   0% /dev/shm  
[email protected]:/data  976M  2.6M  907M   1% /usr/share/nginx/html  

- Coloque lá alguns arquivos e eles podem ser lidos por todos:

/ # ls -la /usr/share/nginx/html

total 36 drwxr-xr-x 1 root root  4096 Aug 20 11:48 . drwxr-xr-x 5 root
root  4096 Aug 20 11:36 ..
-rw-r--r-- 1 root root   537 Aug 20 11:48 50x.html
-rw-r--r-- 1 root root   612 Aug 20 11:48 index.html  
drwx------ 1 root root 16384 Aug 20 11:23 lost+found
-rw-r--r-- 1 root root   310 Aug 20 11:48 test.php

Resultado desejado:

Qualquer que seja o novo container nginx, montei o SSHFS remoto e tenho as mesmas informações procuradas pelo usuário.

Resultado obtido:

O Nginx não lê o conteúdo de / usr / share / nginx / html. Atua como não há arquivo de índice.
Nada aparece no navegador:

Logsnginx:

/#tail/var/log/nginx/error.log2017/08/2015:47:16[crit]139#0:*3stat()"/usr/share/nginx/html/" failed (13: Permission denied), client: 192.168.122.247, server: ajnouri.local, request: "GET / HTTP/1.1", host: "192.168.122.100"  
2017/08/20 15:47:16 [crit] 139#0: *3 stat() "/usr/share/nginx/html/404.html" failed (13: Permission denied), client: 192.168.122.247, server: ajnouri.local, request: "GET / HTTP/1.1", host: "192.168.122.100"  
2017/08/20 15:47:16 [crit] 139#0: *3 stat() "/usr/share/nginx/html/404.html" failed (13: Permission denied), client: 192.168.122.247, server: ajnouri.local, request: "GET / HTTP/1.1", host: "192.168.122.100"  

Parece que "www-data" precisa gravar no diretório.

####################### UPDATE

Assim, conseguiu criar um usuário "www-data", já que era um usuário comum no servidor, e o cliente sshfs conseguiu montar o "/ var / www" usando o "www-data"

No servidor, alterei o proprietário do diretório pessoal "www-data" (/ var / www) para www-data: www-data

/ # chown -R www-data: www-data / var / www

/ # ls -la /var/www
total 36
drwxr-xr-x 1 www-data www-data  4096 Aug 20 11:48 .
drwxr-xr-x 5 root     root      4096 Aug 20 11:36 ..
-rw-r--r-- 1 www-data www-data   537 Aug 20 11:48 50x.html
-rw-r--r-- 1 www-data www-data   612 Aug 20 11:48 index.html
drwx------ 1 www-data www-data 16384 Aug 20 11:23 lost+found
-rw-r--r-- 1 www-data www-data   310 Aug 20 11:48 test.php

######################

Parece não resolver o problema.

O contêiner Nginx (cliente sshfs) e o servidor sshfs usam o mesmo sistema operacional:

/ # lsb_release -a

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:    14.04
Codename:   trusty
    
por AJN 20.08.2017 / 14:41

2 respostas

0

  1. Tente montar o sshfs em www-data, como aqui
  2. Tente definir o diretório raiz fora do sshfs e conecte-se ao site
  3. Verifique se você tem linha na configuração

    index index.html index.htm;

ou conectar-se ao site por link completo, por exemplo, 192.168.0.20/index.html

  1. tail -f você acessa o nginx e registra erros
por 24.08.2017 / 13:19
0

Para aqueles que podem ajudar no futuro, tive esse problema e, depois de pesquisar um pouco mais, descobri que adicionar -o allow_other à chamada de montagem conseguiu fazer com que funcionasse

Não faz ideia do que está fazendo sob o capô, ou porque é necessário (definir uid ou gid não faz nada), mas lá vamos nós.

Fonte: link

    
por 08.02.2018 / 20:44