Bricked meu servidor Ubuntu não pode mais iniciar nem logar mais

Eu instalei um host virtual (KVM) com o Ubuntu Server 14.04.3 LTS. Agora passo a última semana configurando o apache, o módulo owncloud e outras coisas.

No entanto, tudo funcionou muito bem até que eu segui a recomendação do Owncloud https://doc.owncloud.org/server/8.0/admin_manual/installation/installation_wizard.html#setting-strong-directory-permissions

Eles escreveram que a maneira mais fácil seria criar o script com o seguinte conteúdo

#!/bin/bash
ocpath='/var/www/owncloud'
htuser='www-data'
htgroup='www-data'
rootuser='root' # On QNAP this is admin

find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750

chown -R ${rootuser}:${htgroup} ${ocpath}/
chown -R ${htuser}:${htgroup} ${ocpath}/apps/
chown -R ${htuser}:${htgroup} ${ocpath}/config/
chown -R ${htuser}:${htgroup} ${ocpath}/data/
chown -R ${htuser}:${htgroup} ${ocpath}/themes/

chown ${rootuser}:${htgroup} ${ocpath}/.htaccess
chown ${rootuser}:${htgroup} ${ocpath}/data/.htaccess

chmod 0644 ${ocpath}/.htaccess
chmod 0644 ${ocpath}/data/.htaccess

Bem, eu não vi nenhum conteúdo crítico, apenas chmods regulares para root e www-data. Então eu criei um script.sh com o conteúdo acima na minha pasta www e execute-o pelo sudo ./script.sh

Então, isso demorou muito e, do contrário, apareceram erros de privilégios perdidos enquanto o script ainda estava em execução (o que foi muito engraçado, já que o sudo fez bem com a senha correta).

Depois que o script terminou suas tarefas, tentei mudar o sudo su para o modo raiz e vi o que aconteceu: Meu usuário principal do Ubuntu perdeu o direito de executar o sudo su e nem mesmo o sudo era possível.

Bem, depois tentei reiniciar o host virtual para iniciar o shell de root no modo de recuperação, mas ele pára entre a inicialização com o kernel panic.

Alguma ideia do que aconteceu? Este script pode seguir um link simbólico para o meu diretório raiz? Você vê alguma chance de consertar meu servidor. Caso contrário, perco uma semana de trabalho :(

— Mkay
fonte

Tudo feito nesse script parece bloqueado para o caminho do $ ocpath - o sudoer e os arquivos do sistema estão em / etc. Eu não vejo como esse script pode atualizar esse arquivo. Você pode ter corrupção de dados? Tente um live cd do Ubuntu e verifique com fsck?

— bshea

De relance, o script parece estar configurado corretamente. findno debian não retorna ou segue links simbólicos a menos que -Lseja usado.

— Frank Thomas

Não é útil em consertar isso, mas 1) Primeiro, use uma impressão simples antes de executar tal comando. Por exemplo, find ${ocpath}/ -type f -ls2) Não tenho certeza por que eles usam find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640. Por que não simplesmente find ${ocpath}/ -type f -exec hmod 0640 +(mais curto e mais eficiente). 3) Verifique Ocpath. ocpath = '/ var / www / owncloud'. Certifique-se de que não haja espaço acidental. Por exemplo, ocpath = '/ var / www / owncloud' ou similar.

— Hennes

Além disso, é melhor usar cotações para variáveis em scripts de shell. Você pode fazer uma grande bagunça se, por exemplo (como disse o @Hennes), você colocar um espaço extra nas definições das variáveis. Por exemplo:chown -R ${rootuser}:${htgroup} "${ocpath}/"

— emi

Como sugerido por @bshea, se você perdeu seu acesso root a um Linux, inicialize-o com um Live System (em um CD, em um USB, via PXEBoot, etc). Se este sistema estiver dentro de um KVM, você provavelmente terá acesso ao seu disco rígido virtual. Se sim, você pode montá-lo e tentar consertá-lo. Se você precisar instalar coisas, provavelmente vai querer usar chroot.

— emi