Permissoes em segundo HD

[jrdbeto]

tenho um HD de 1 TERA que guardo meus arquivos de tudo, onde tenho um diretório "Instalações" , acontece que esse HD foi criado no tempo do Windows 7 e agora tenho Windows 10 não consigo abrir nada, diz que não tenho permissão...   o que fazer???

[PedraX]

Botão direito mouse, propriedades,segurança:marcar controle total para todos.

[Visitante]

1 hora atrás, jrdbeto disse:

tenho um HD de 1 TERA que guardo meus arquivos de tudo, onde tenho um diretório "Instalações" , acontece que esse HD foi criado no tempo do Windows 7 e agora tenho Windows 10 não consigo abrir nada, diz que não tenho permissão...   o que fazer???

Esse Windows 10 é bem frescão nisso aí mesmo. Passei por isso também. Primeira coisa, é lógico, ser administrador. Segunda, desativar UAC. Terceira, continua negando acesso, mas você consegue permitir a cada vez. Aí eu resolvi criando novas pastas e copiando o conteúdo de cada. No meu caso, por ter dual boot com o 7, eu pude despois excluir as antigas. No seu caso, se não tem, pode usar um Linux Live.

[jrdbeto]

tenho um boot linux em um pendrive... vou ver   - obrigado

 

[Marcos FRM]

17 minutos atrás, Walter C. Catelan disse:

Esse Windows 10 é bem frescão nisso aí mesmo. Passei por isso também. Primeira coisa, é lógico, ser administrador. Segunda, desativar UAC. Terceira, continua negando acesso, mas você consegue permitir a cada vez. Aí eu resolvi criando novas pastas e copiando o conteúdo de cada. No meu caso, por ter dual boot com o 7, eu pude despois excluir as antigas. No seu caso, se não tem, pode usar um Linux Live.

 

Nada disso é necessário. Especialmente o UAC, que não deve ser desativado. Basta aprender como o sistema de permissões do NTFS funciona. Nota: o esquema é o mesmo desde o Windows 2000.

 

Eu gosto da linha de comando. Faria isso no prompt de comando rodando como administrador (considerando o volume em questão sendo E:):

 

icacls E: /grant USUARIO:(OI)(CI)(F)

 

Adiciona uma permissão de controle total ao seu usuário, que será propagada via herança a tudo que estiver dentro do volume. Observação:  a cada reinstalação do sistema, mesmo que você crie um usuário com o mesmo nome anterior, seu SID mudará e a permissão deverá ser adicionada novamente.

 

Se você não se preocupar muito em restringir o acesso, pode substituir USUARIO por *S-1-1-0:

 

icacls E: /grant *S-1-1-0:(OI)(CI)(F)

 

S-1-1-0 é o SID que corresponde a "Todos". A vantagem de usá-lo no lugar de "Todos" é que é portável entre línguas diferentes. Se você rodar um Windows em alemão, por exemplo, funcionará. "Todos" não funcionaria. O SID de "Todos" é fixo e resiste a reinstalações do sistema.

 

Esse segundo comando é basicamente o mesmo recomendado pelo @PedraX . Com a diferença que as ACLs padrão aplicadas à raiz do volume não incluem uma entrada para "Todos". Nós a colocamos manualmente.

 

Atenção: nunca rode esse comando no volume onde o Windows está instalado! Deve ser usado apenas em volumes secundários, usados só para dados do usuário.

[Visitante]

@Marcos FRM querido, como eu disse antes. Mesmo permitindo acesso total às pastas e subpastas (por linha de comando ou interface, o efeito é o mesmo) e até tomando a propriedade, no MEU caso, precisava reautorizar a cada acesso.

[Marcos FRM]

@Walter C. Catelan  Quando se deparar com esse problema novamente, abra, se possível, um tópico no fórum, me mencione e poste a saída dos comandos:

 

icacls <unidade>:

icacls <unidade>:\PASTA

 

Para sabermos quais ACLs estão causando problema. As ACLs padrão aplicadas à raiz de volumes NTFS não possuem nenhuma negação (que sempre têm prioridade) que possa influenciar numa ACL liberando acesso a usuários específicos. Algo que poderia complicar seria um Integrity Level (IL) alto em alguma pasta, porém é muito raro ver ILs configurados em dados de usuários.

[Visitante]

53 minutos atrás, Marcos FRM disse:

@Walter C. Catelan  Quando se deparar com esse problema novamente, abra, se possível, um tópico no fórum, me mencione e poste a saída dos comandos:

 

icacls <unidade>:

icacls <unidade>:\PASTA

 

Para sabermos quais ACLs estão causando problema. As ACLs padrão aplicadas à raiz de volumes NTFS não possuem nenhuma negação (que sempre têm prioridade) que possa influenciar numa ACL liberando acesso a usuários específicos. Algo que poderia complicar seria um Integrity Level (IL) alto em alguma pasta, porém é muito raro ver ILs configurados em dados de usuários.

OK, se ocorrer.