Quero configurar minhas configurações de backup mensal completo para fazer backup apenas dos meus dados de usuário, não do SO. Se eu precisasse fazer uma restauração completa, eu reinstalaria o Ubuntu e então adicionaria meus dados de volta. Todos os dados específicos para mim estão contidos no diretório /home, incluindo as alterações de configurações, perfis, etc. que eu faço em vários aplicativos, como Tbird, Firefox, etc.? (Eu faço backups incrementais das pastas mais usadas com mais frequência.) Eu sou o único usuário neste sistema Ubuntu 22.04.
O GParted de repente requer root. Isso ocorreu depois que tentei abrir uma pasta 'lost+found' em um usb criptografado que pediu root, duas vezes, mas eu saí antes de abrir no final, o que pode estar conectado?
Depois de digitar a senha de root, o GParted começou a escanear os locais e demorou tanto para abrir que o fechei, pois nunca tinha feito isso antes.
Li que as GUIs não devem ser executadas com privilégios de root, então há uma maneira de voltar a usar sem?
Alguém pode me dizer se é seguro usar o GParted como root ou se devo desinstalar e reinstalar para que funcione como antes? Qual seria a maneira recomendada de desinstalar/reinstalar?
Eu fiz uma coisa muito idiota.
Na raiz de um cartão SSD, executei: sudo chown -R root:root .quando deveria ter executado: sudo chown -R myusername:myusername .Agora não consigo acessar arquivos/diretórios de todo o SSD quando conectado com meu nome de usuário
Entrar no terminal sudo roote navegar até o SSD agora mostra um diretório vazio.
Resultados de sudo ls -al:
drwxrwxrwx 3 root root 4096 Feb 11 2023 foo
drwxrwxrwx 2 root root 4096 Nov 28 14:26 fii
drwxr-xr-x 5 root root 4096 Nov 28 14:26 thumb
drwxrwxrwx 2 root root 4096 Nov 28 14:26 fooder
-rwxr-xr-x 1 root root 69 Nov 18 2023 datab.vdf
drwx------ 2 root root 16384 Dec 6 17:35 lost+found
drwxrwxrwx 2 root root 4096 Nov 28 14:26 meta
-rw-rw-rw- 1 root root 4656 Mar 23 2023 noob.out
drwxrwxrwx 2 root root 4096 Feb 10 2023 nerds
find . -type d -exec chmod +x {} \\;
Descobri que o comando acima não é a solução.
Não consigo mudar para um diretório, mas posso listar seu conteúdo com ls -la, e fica assim.
d????????? ? ? ? ? ? .
d????????? ? ? ? ? ? ..
?????????? ? ? ? ? ? '30drop - Tools For The Dimensional Step [2015] [FLAC]'
?????????? ? ? ? ? ? 'Ada Kaleh - Zâna Zorilor'
?????????? ? ? ? ? ? 'Aes Dana - Perimeters [2011] [FLAC]'
?????????? ? ? ? ? ? 'After Hour - Feel It & Waterfalls [1991] [FLAC]'
Tentei mudar o proprietário e tentei definir permissões para 777, mas nenhuma delas funciona. É permission deniedou operation not permitted. Os arquivos estão definitivamente lá e não foram excluídos, mas como faço para recuperar o acesso a eles?
Eu realmente não tinha ideia de por que um chmod -xcomando recursivo seria perigoso assim, mas definitivamente é.
Estou no Ubuntu 20.04 e tentando executar um comando como root, mas sem usar o sudo e, em vez disso, usando o sticky bit.
Li esta resposta , mas não consigo fazê-la funcionar.
Criei um script chamado whoami_rootpara mostrar ao usuário como ele está sendo executado.
Saída de cat whoami_root:
#!/bin/bash
whoami
Eu corri sudo chown root whoami_rootesudo chmod u+s whoami_root
Saída de ll whoami_root:
-rwsr-xr-x 1 root root 20 Nov 6 23:33 whoami_root
Saída de./whoami_root
myuser
Por que ele parece ignorar o bit suid e ser executado como myuser em vez de root?
Tenho dois compartilhamentos samba no Kubuntu 24.04, um em uma partição ext4 e o outro em uma partição NTFS.
Quero acessá-los do Android. Lá, o VLC pode vê-los e acessá-los muito bem, ver os arquivos, reproduzir a mídia. Mas nenhum gerenciador de arquivos pode. Alguns podem mostrar os principais locais e pastas, mas não os arquivos, e alguns também dizem "Acesso negado".
O problema parece estar nas permissões.
Vejo isso no Samba Status:
- para o da partição ext4:
- para o da partição NTFS:
/etc/samba/smb.conf contém estas linhas:
; write list = root, @lpadmin
[DEPO-VIDEO]
path = /home/cip/Mounted/Samba/DEPO-VIDEO
available = yes
valid users = cip
read only = no
browseable = yes
public = yes
[Ntfs-Depo-VIDEOOO]
path = /home/cip/Mounted/Samba/Ntfs-Depo-VIDEOOO
available = yes
valid users = cip
read only = no
browseable = yes
public = yes
chmod não pode ser usado, ao que parece:
chmod -v 751 /media/cip
chmod: changing permissions of '/media/cip': Operation not permitted
failed to change mode of '/media/cip' from 0750 (rwxr-x---) to 0751 (rwxr-x--x)
Quero negar permissão de exclusão para tudo o que está em /home/don/testdir ou em seus subdiretórios para todos os aplicativos, sem impedir a criação ou gravação. Pelo que entendi, isso não é possível com a ACL convencional porque a permissão de gravação é tudo (criar + gravar + excluir) ou nada, não posso negar apenas excluir enquanto permite criar e gravar.
Eu tentei chattr +apara esse diretório, mas se depois de executar este comando o subdiretório for adicionado e nesse subdiretório o arquivo for adicionado, isso não impedirá a remoção desse arquivo, por exemplo testdir/subdir/file.txt.
Sou novo no AppArmor. Tentei criar a seguinte regra e salvá-la como /etc/apparmor.d/home.don.testdirmas não funcionou
# Profile to prevent any process from deleting files in /home/don/testdir
profile prevent-delete {
# Allow read, write, and execute within the directory
/home/don/testdir/ rix,
/home/don/testdir/** rwlix,
# Explicitly deny delete operations
deny /home/don/testdir/** D,
}
Recebi um erro do analisador AppArmor para /etc/apparmor.d/home.don.testdir no perfil /etc/apparmor.d/home.don.testdir na linha 9: erro de sintaxe, TOK_ID inesperado, esperando TOK_MODE.
Eu tenho uma grande pasta de dados em um dos meus servidores que, por motivos muito longos, gostaria de migrar para um NAS dedicado (Openmediavault) e depois compartilhar de volta com o servidor existente.
Dentro dele estão arquivos que pertencem a www-data (pasta de dados nextcloud), will (me), media (uma pasta de dados plex) e cctv (um armazenamento de gravação para câmeras), entre alguns outros conteúdos.
Existe uma maneira fácil de manter uma estrutura de propriedade como essa em um armazenamento compartilhado ou seria melhor dividir cada uma das pastas em compartilhamentos separados e montá-las individualmente?
Idealmente, eu gostaria simplesmente de manter os proprietários existentes das pastas e arquivos. Clonei a imagem da unidade para teste, mas apesar de selecionar a configuração "Herdar permissões" que soa correta
The permissions on new files and directories are normally governed by create mask and directory mask but the inherit permissions parameter overrides this. This can be particularly useful on systems with many users to allow a single share to be used flexibly by each user.
Mas ao montar a unidade no servidor (clonado para teste) através de uma entrada fstab
//10.10.10.65/willzpool /willzpool cifs credentials=/root/smbcredentials 0 0
tudo dentro do compartilhamento pertence ao root. Mesmo como root, não consigo fazer nada dentro do compartilhamento.
Estou faltando alguma coisa ou meu objetivo é impossível?
Um programa, pwrstat por exemplo, pode ser executado por IDs de usuário comuns se o setuid (chmod 4xxx) estiver definido e o arquivo pertencer ao root. Quando a permissão setuid é definida, a entidade é executada como se fosse o proprietário do arquivo. Se for root, isso implica privilégios de root. Deve-se seguir que se um shell tiver setuid e for de propriedade do root, ele deverá ser executado com privilégios de root. Um exemplo seria
#!/bin/bash
cp $1 /var/aa.aa
No entanto, alguém que não seja o root executando o shell de exemplo (com permissão -rwsr-xr-x) obtém permissão negada na cópia.
OK, um programa funciona, um shell não. Tentei criar um programa C simples que usa
system ()
Mesmo resultado.
A questão principal aqui é por que o setuid não permite que um shell seja executado como root. Uma subquestão é por que um programa C não pode emitir os comandos que estariam nesse shell?
Alguns dos usuários de alta reputação estão votando para encerrar esta questão, pois ela é semelhante às perguntas anteriores, EXCETO que essas perguntas e respostas anteriores são complexas. Por favor, não esqueça que muitos usuários aqui provavelmente se perderiam nos uids, setuid, seteuids e outros enfeites, o que faz sentido para aqueles que provavelmente estão prontos para fazer um exame de certificação de administração Linux.
Eu uso o visualizador Weasis Dicom (da Snap Store) para visualizar arquivos DICOM médicos.
No Ubuntu 20.04LTS e 22.04LTS, na página Snap Store, uma vez baixado, há um botão para alterar Permissões.
Isso abre um menu e a última opção permite ativar/desativar o acesso a dispositivos de armazenamento removíveis.
Não consigo encontrar uma opção semelhante no 24.04LTS - há um botão com três pontos próximo à barra de título, mas isso só me dá a opção de desinstalar.
Como posso selecionar permissões (especificamente para acessar dispositivos de armazenamento removíveis) em 24.04LTS?
Se isso for algo definido pelos produtores do software, deixe-me saber por comentário e entrarei em contato com eles, mas se puder ser alterado no Snap Store ou em outra configuração no Ubuntu, ficaria muito grato pela ajuda - posso estar faltando algo óbvio!
Tenho certeza de que este não é um problema de permissão padrão, pois estou executando o software como um usuário padrão e o mesmo usuário pode acessar as pastas relevantes via GUI (Arquivos) ou navegar até lá em um terminal.
Preciso usar isso porque tenho os arquivos em uma partição criptografada que o Weasis está tratando como um dispositivo de armazenamento removível. Eu sei que os próprios arquivos podem ser lidos pelo Weasis porque se eu copiar os arquivos para minha pasta /home (por exemplo), o Weasis poderá acessá-los. Se eles estiverem na partição criptografada, o Weasis não verá a partição. A partição está em/media - mas quando navego até lá dentro do Weasis para abrir um arquivo, ele não mostra nada em/media.
Obrigado.