Script bash que pode ser chamado em casa, mas não no diretório de scripts

Question

Estou tendo um erro muito estranho ao tentar fazer um script ser chamado. Eu tenho um diretório de scripts em / srv / projectname / scripts onde eu armazeno você sabe scripts para ser chamado como tarefas cron para projetos diferentes. Eu estou tentando adicionar um novo e vendo um comportamento muito estranho. Na depuração eu reproduzo usando este conjunto de comandos

de / srv / projectname / scripts cria um arquivo para criar um arquivo

vi helloworld.sh

insira o texto exatamente:

#!/usr/bin/env bash

echo "Hello World!"

Torne o script executável e tente chamá-lo:

chmod +x helloworld.sh
./helloworld.sh

O que dá:

-bash: ./helloworld.sh: Permission denied

Verifique se não há um erro de código:

bash helloworld.sh

O que dá:

Hello World!

Copie o script para casa e chame-o:

cp helloworld.sh ~/helloword.sh
~/helloword.sh

O que dá:

Hello World!

Eu não tenho ideia do que está acontecendo. Eu tentei um monte de variantes onde eu dou o caminho completo, mesmo erro, ou se eu sudo que não dá erro, mas também não imprime "Olá mundo!".

Outros detalhes: Correndo em: Ubuntu 12.04.4 LTS Eu também notei que não posso tab-complete para o nome completo de um script que me dá esse erro, mas posso uma vez que eu mudei. O diretório / srv / projectname é um repositório git, mas este script ainda não foi adicionado a ele, porque geralmente só faço isso quando está funcionando ainda.

ls -l linhas para o script e o diretório de scripts são

-rwxrwxr-x 1 ubuntu ubuntu     41 Apr 21 20:25 helloworld.sh
drwxrwxr-x 3 ubuntu ubuntu 4096 Apr 21 20:25 scripts

respectivamente

Qualquer ajuda seria incrível.

EDITAR: Gilles teve a resposta. Para salvar alguém que tenha esse problema, pesquise no Google.

sudo mount /srv/projectname/ -o remount

recarrega o fstab editado e tudo funciona novamente.

    

Answer 1

As permissões do arquivo dizem que é executável, mas o arquivo não é executável. Existem três razões pelas quais isso pode acontecer.

• Você não aprofundou o suficiente nas permissões de arquivo - existe uma lista de controle de acesso que torna o arquivo não executável para você. Você pode ver a ACL de um arquivo com o comando getfacl /path/to/file . Esse não é o caso aqui, pois ls -l mostra que não há ACL no arquivo (haveria + no final das permissões, por exemplo, -rwxr-xr-x+ ).
• O arquivo é armazenado em um volume montado com a opção noexec . Esta opção está implícita por ter users em uma linha fstab (se você quiser tornar um sistema de arquivos montável pelo usuário e permitir que os usuários executem arquivos nele, use noauto,users,exec ). Essa opção de montagem faz com que todos os arquivos comuns sejam não executáveis, independentemente de suas permissões.
• O arquivo é um script que faz referência a um interpretador que não é executável em sua linha shebang ou a um binário vinculado dinamicamente que faz referência a um carregador dinâmico que não é executável. Este não é o caso aqui dado que copiar o arquivo resulta em um arquivo que você pode executar (e /usr/bin/env é executável de qualquer maneira).

Por um processo de eliminação, o arquivo está em um volume montado com a opção noexec .

As únicas soluções alternativas são:

• Não monte o volume com a opção noexec . Esta opção não tem implicações de segurança (ao contrário de nosuid e nodev , que fazem). É principalmente útil para sistemas de arquivos sem noção de permissões de execução, onde você pode escolher entre tornar tudo executável ou nada.
• Copie o arquivo antes de executá-lo.
• Use uma montagem de bind ou bindfs para criar uma visão do sistema de arquivos onde os arquivos executáveis são executáveis.
• Invoque o interpretador ou o carregador dinâmico explicitamente, por exemplo aqui bash helloworld.sh . Isso não executa helloworld.sh , ele executa /bin/bash , que lê helloworld.sh .