Permissões NTFS, SID, ACL, propriedade, herança e criptografia EFS

Você retirou o HD ou SSD de um computador antigo, conectou a outra máquina com Windows 11 e tentou abrir seus arquivos pessoais. Entretanto, o Windows apresenta uma mensagem de acesso negado, solicita permissão de administrador ou informa que você não possui autorização para acessar determinada pasta.

Em alguns casos, os arquivos aparecem normalmente no Explorador, mas não podem ser abertos, copiados, modificados ou excluídos. Em outros, determinadas pastas apresentam um símbolo de cadeado.

Esse problema é relativamente comum após a troca de computador, reinstalação do Windows, recuperação de dados ou conexão de um disco utilizado anteriormente em outra instalação do sistema operacional.

O motivo pode estar relacionado a permissões NTFS, identificadores de segurança de usuários antigos, propriedade de arquivos, regras de herança ou criptografia.

O detalhe mais importante é que possuir uma conta de administrador no Windows 11 não garante acesso automático a todos os arquivos armazenados em outro disco.

Neste guia completo da VMIA, vamos explicar como o Windows controla o acesso aos arquivos, como identificar a origem do bloqueio e quais verificações realizar antes de modificar permissões.

1. Por que arquivos de outro HD ficam bloqueados no Windows 11?

Quando você conecta um HD ou SSD utilizado em outro computador, o Windows pode reconhecer normalmente o dispositivo, identificar suas partições e apresentar os arquivos no Explorador.

Entretanto, conseguir visualizar um arquivo não significa necessariamente possuir permissão para acessar seu conteúdo.

Isso acontece porque o NTFS, sistema de arquivos amplamente utilizado pelo Windows, possui mecanismos de controle de acesso.

Esses mecanismos permitem definir quais usuários e grupos podem realizar operações sobre arquivos e pastas.

Entre as operações controladas estão:

• Ler arquivos e listar diretórios.
• Criar arquivos e subpastas.
• Modificar conteúdo.
• Renomear ou excluir arquivos.
• Alterar permissões.
• Modificar o proprietário.

Quando o disco pertenceu a outra instalação do Windows, as permissões podem continuar associadas a contas que não existem no computador atual.

O resultado pode ser uma mensagem de acesso negado.

1.1. Exemplo prático: HD retirado de um computador antigo

Imagine a seguinte situação.

Um usuário possuía um computador com Windows 10 e armazenava documentos na pasta:

D:\Users\Carlos\Documents

Depois de trocar de computador, ele conecta o HD antigo por meio de um adaptador USB.

O Windows 11 reconhece o disco como unidade E:.

Ao tentar acessar:

E:\Users\Carlos\Documents

o sistema apresenta uma mensagem informando que o usuário não possui permissão para acessar a pasta.

O problema pode estar relacionado às permissões mantidas no disco antigo.

Mesmo que o novo computador possua uma conta chamada Carlos, ela não é necessariamente a mesma identidade de segurança utilizada na instalação anterior.

Essa diferença é fundamental para compreender o funcionamento das permissões NTFS.

2. SID: por que o Windows não reconhece automaticamente o usuário antigo?

O Security Identifier, ou SID, é um identificador de segurança utilizado pelo Windows para representar contas de usuários, grupos e outras entidades de segurança.

O Windows não depende exclusivamente do nome visível de uma conta para controlar o acesso aos arquivos.

Ele utiliza identificadores internos.

2.1. Como funciona um SID?

Um SID de usuário local pode apresentar uma estrutura semelhante a:

S-1-5-21-123456789-987654321-456789123-1001

Esse exemplo é ilustrativo.

A estrutura inclui componentes que identificam a autoridade e o domínio de segurança, além de um identificador relativo da conta.

Em contas locais, o SID normalmente incorpora informações associadas à instalação do Windows.

Isso significa que duas contas chamadas Carlos, criadas em instalações diferentes, podem possuir SIDs distintos.

2.2. O que acontece após reinstalar o Windows?

Considere um computador que utilizava uma conta local chamada Usuario.

Antes da reinstalação, essa conta possuía determinado SID.

Depois de uma instalação limpa do Windows 11, uma nova conta com o mesmo nome é criada.

Embora o nome seja idêntico, o SID pode ser diferente.

Consequentemente, permissões NTFS associadas exclusivamente ao SID antigo podem não conceder acesso à nova conta.

Isso explica por que arquivos pessoais podem ficar inacessíveis depois de uma reinstalação, mesmo quando o usuário utiliza o mesmo nome e senha.

2.3. Como descobrir o SID do usuário atual?

Abra o Prompt de Comando e execute:

whoami /user

O Windows apresentará o nome da conta e seu identificador de segurança.

Exemplo ilustrativo:

NOME DE USUÁRIO        SID
PC-NOVO\Carlos         S-1-5-21-...-1001

No PowerShell, também é possível executar:

[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value

O comando retorna o SID associado à identidade atual do processo.

2.4. Como verificar os grupos do usuário?

Execute:

whoami /groups

Esse comando apresenta os grupos e atributos presentes no token de segurança atual.

Ele é útil para verificar se o processo possui determinados grupos habilitados.

Entretanto, pertencer ao grupo Administradores não significa que todo programa esteja executando com privilégios elevados.

O Controle de Conta de Usuário, conhecido como UAC, pode fornecer um token restrito para processos iniciados normalmente.

3. ACL NTFS: como o Windows decide quem pode acessar arquivos

As Access Control Lists, ou ACLs, são estruturas utilizadas para definir regras de acesso.

No NTFS, o descritor de segurança de um arquivo pode conter uma Discretionary Access Control List (DACL), responsável por estabelecer permissões de acesso.

Cada entrada da lista é conhecida como Access Control Entry, ou ACE.

Uma ACE pode identificar um usuário ou grupo e definir permissões permitidas ou negadas.

3.1. Exemplo de permissões NTFS

Imagine uma pasta com as seguintes entradas:

Identidade	Permissão
SYSTEM	Controle total
Administradores	Controle total
SID do usuário antigo	Modificar
Usuários	Leitura

O comportamento real depende das permissões aplicáveis, da herança, do token de acesso e de outras regras do sistema.

O Windows não decide o acesso simplesmente verificando se existe uma entrada com o nome do usuário atual.

Ele avalia o descritor de segurança e os direitos solicitados.

3.2. Permissões permitir e negar

As ACLs podem conter entradas que concedem ou negam direitos.

Uma entrada de negação aplicável pode impedir determinada operação mesmo quando existem outras permissões.

Entretanto, o resultado depende da combinação das ACEs, dos direitos solicitados e das regras de avaliação.

Por isso, modificar uma única entrada sem compreender o restante da ACL pode produzir resultados inesperados.

3.3. Como visualizar permissões pelo Explorador de Arquivos

No Windows 11:

1. Abra o Explorador de Arquivos.
2. Localize o arquivo ou pasta.
3. Clique com o botão direito e selecione Propriedades.
4. Abra a guia Segurança.
5. Examine os usuários e grupos apresentados.
6. Se necessário, selecione Avançadas para consultar detalhes.

Na janela de segurança avançada, é possível examinar o proprietário, as entradas de permissão e a herança.

Neste momento, o objetivo é apenas observar as configurações.

Não altere permissões antes de identificar se existe criptografia ou outro mecanismo responsável pelo bloqueio.

4. Como identificar permissões antigas com icacls

O utilitário icacls permite consultar e administrar permissões de arquivos e pastas NTFS.

Ele é uma ferramenta importante para diagnósticos de acesso negado.

4.1. Consultando as permissões de uma pasta

Abra o Prompt de Comando e execute:

icacls "E:\Users\Carlos\Documents"

O comando apresenta as entradas de controle de acesso associadas à pasta.

Um resultado ilustrativo pode conter:

E:\Users\Carlos\Documents
    NT AUTHORITY\SYSTEM:(F)
    BUILTIN\Administrators:(F)
    S-1-5-21-...-1001:(M)

As letras representam direitos ou conjuntos de direitos.

Código	Significado
F	Controle total
M	Modificar
RX	Ler e executar
R	Leitura
W	Gravação

As entradas também podem apresentar indicadores de herança.

4.2. Por que aparecem números em vez de nomes?

Quando o Windows não consegue resolver um SID para uma conta conhecida, ele pode apresentar o identificador numérico.

Isso pode acontecer quando a conta pertence a uma instalação antiga ou a um domínio indisponível.

Entretanto, um SID não resolvido não significa automaticamente que a entrada esteja incorreta ou que seja a causa do bloqueio.

É necessário verificar quais direitos a entrada concede ou nega e quais outras permissões estão presentes.

4.3. Verificando permissões com PowerShell

O PowerShell oferece o comando Get-Acl.

Exemplo:

Get-Acl -LiteralPath "E:\Users\Carlos\Documents" |
Format-List Owner,AccessToString,AreAccessRulesProtected

Esse comando permite consultar:

• Proprietário.
• Entradas de acesso.
• Estado de proteção da herança da DACL.

Ele não modifica o descritor de segurança.

4.4. Exibindo cada entrada de permissão

Para uma análise mais detalhada:

$Acl = Get-Acl -LiteralPath "E:\Users\Carlos\Documents"

$Acl.Access |
Select-Object IdentityReference,
              FileSystemRights,
              AccessControlType,
              IsInherited,
              InheritanceFlags,
              PropagationFlags |
Format-Table -AutoSize

Esse procedimento ajuda a identificar entradas herdadas, regras explícitas e permissões associadas a identidades antigas.

Se o próprio descritor de segurança não puder ser consultado com a identidade atual, o comando poderá retornar acesso negado. Nesse caso, registre a falha e avalie as permissões administrativas disponíveis.

5. Propriedade de arquivos: por que ser administrador não significa ser proprietário?

No Windows, cada arquivo ou pasta possui um proprietário registrado em seu descritor de segurança.

A propriedade possui papel importante na administração das permissões.

Entretanto, o proprietário não recebe automaticamente todos os direitos de leitura e gravação sobre o conteúdo.

Em geral, a propriedade permite administrar a DACL, respeitadas as regras e políticas aplicáveis.

5.1. Proprietário antigo após troca de computador

Um arquivo pode continuar associado ao SID do usuário da instalação anterior.

Por exemplo:

Proprietário:
S-1-5-21-...-1001

A nova conta do Windows 11 pode possuir outro SID.

Isso não significa necessariamente que o arquivo esteja corrompido.

Significa que as informações de propriedade foram preservadas.

5.2. Como verificar o proprietário pelo PowerShell

Execute:

(Get-Acl -LiteralPath "E:\Users\Carlos\Documents").Owner

O comando retorna a identidade registrada como proprietária.

Se o Windows não conseguir resolver a identidade, o resultado poderá apresentar um SID.

5.3. Por que não assumir imediatamente a propriedade?

Alterar a propriedade de uma pasta inteira pode modificar o comportamento de aplicativos e sistemas que dependem de permissões específicas.

Isso é especialmente importante em diretórios como:

• Windows
• Program Files
• ProgramData
• Pastas de perfis antigos
• Diretórios de aplicativos
• Pastas corporativas com permissões específicas

Além disso, assumir a propriedade não recupera automaticamente arquivos criptografados com EFS.

Antes de modificar a propriedade, identifique a natureza dos dados e preserve uma cópia de segurança quando possível.

6. Herança NTFS: por que algumas subpastas abrem e outras apresentam acesso negado?

O NTFS permite que permissões sejam herdadas de diretórios superiores.

Esse mecanismo facilita a administração de grandes estruturas de arquivos.

Entretanto, a herança pode estar desativada ou modificada em determinadas pastas.

6.1. Como funciona a herança?

Imagine a estrutura:

E:\
└── Usuarios
    └── Carlos
        ├── Documentos
        ├── Imagens
        └── Projetos

A pasta Usuarios pode possuir permissões que são propagadas às subpastas.

Entretanto, a pasta Projetos pode possuir uma DACL protegida contra herança, com regras explícitas próprias.

Nesse caso, o comportamento de acesso pode ser diferente.

6.2. Permissões explícitas e herdadas

Tipo	Característica
Explícita	Configurada diretamente no objeto
Herdada	Recebida de um diretório superior
Herança protegida	DACL não recebe automaticamente ACEs herdáveis do pai
ACE de negação	Pode impedir direitos específicos

O resultado final depende da avaliação completa das permissões.

6.3. Como verificar se a herança está protegida

Execute:

$Acl = Get-Acl -LiteralPath "E:\Usuarios\Carlos\Projetos"

$Acl.AreAccessRulesProtected

Se o resultado for True, a DACL está protegida contra herança.

Se for False, a DACL não está marcada como protegida.

Isso não informa, por si só, se o usuário possui acesso.

Também não significa que todas as entradas existentes sejam herdadas.

6.4. Por que ativar a herança indiscriminadamente pode ser perigoso?

Alterar a herança pode modificar permissões de diversas pastas e arquivos.

Em determinados casos, permissões mais amplas podem ser propagadas para conteúdos que deveriam permanecer restritos.

Em outros, regras necessárias podem ser substituídas.

Por isso, a correção deve considerar a estrutura original e a finalidade dos diretórios.

7. EFS: quando o problema não é permissão, mas criptografia

O Encrypting File System, conhecido como EFS, é um recurso de criptografia de arquivos disponível em edições compatíveis do Windows.

Ele permite proteger o conteúdo de arquivos armazenados em NTFS.

Essa proteção é diferente das permissões tradicionais.

Um arquivo criptografado com EFS pode continuar inacessível mesmo depois de o usuário assumir a propriedade e receber controle total na ACL.

Isso acontece porque o acesso ao conteúdo depende do material criptográfico necessário à descriptografia.

7.1. Como reconhecer arquivos EFS?

O Explorador de Arquivos pode apresentar indicadores visuais de criptografia, dependendo das configurações.

Entretanto, a aparência não deve ser utilizada como único critério.

Para verificar o estado de criptografia, utilize:

cipher /c "E:\Usuarios\Carlos\Documentos\arquivo.docx"

O comando consulta informações relacionadas à criptografia do arquivo.

Se o arquivo estiver criptografado com EFS, poderão ser apresentadas informações sobre os certificados associados.

7.2. Por que o EFS causa problemas depois de reinstalar o Windows?

O EFS utiliza certificados e chaves criptográficas associados à proteção do arquivo.

Após uma reinstalação limpa do Windows, o usuário pode não possuir mais o certificado e a chave privada necessários.

Nesse cenário, modificar permissões NTFS não resolve o problema.

7.3. É possível recuperar arquivos EFS?

A recuperação depende da disponibilidade das credenciais criptográficas apropriadas.

Entre as possibilidades legítimas estão:

• Certificado EFS original acompanhado da chave privada.
• Backup válido do certificado e da chave.
• Agente de recuperação de dados previamente configurado.
• Instalação original ainda acessível com as chaves necessárias.

Sem o material criptográfico adequado, a recuperação pode ser inviável.

Por isso, é essencial verificar a presença de EFS antes de alterar permissões ou reinstalar sistemas.

8. Cadeado no arquivo: ele sempre significa acesso negado?

Não.

Um ícone de cadeado pode estar relacionado a diferentes condições, dependendo da versão do Windows, do aplicativo e das extensões instaladas.

Não existe uma regra universal segundo a qual todo arquivo com cadeado possui permissões NTFS incorretas.

O símbolo pode estar associado a permissões restritas, recursos de proteção ou indicadores adicionados por aplicativos.

Portanto, o diagnóstico deve considerar o comportamento real.

8.1. Diferencie os sintomas

Sintoma	Hipótese inicial
Pasta solicita autorização administrativa	Permissões ou propriedade
Arquivo aparece, mas não abre	ACL, EFS ou problema do aplicativo
Apenas algumas subpastas falham	Herança ou regras explícitas
Arquivo EFS não pode ser lido	Ausência de chave criptográfica
Disco inteiro está bloqueado	Investigar BitLocker
Arquivo apresenta cadeado, mas abre normalmente	Indicador visual sem bloqueio efetivo

8.2. E se o disco estiver protegido com BitLocker?

BitLocker e EFS são tecnologias diferentes.

O BitLocker protege volumes, enquanto o EFS protege arquivos individualmente.

Se o volume estiver bloqueado pelo BitLocker, pode ser necessária a chave de recuperação correspondente.

Alterar ACLs não substitui o desbloqueio criptográfico do volume.

9. Diagnóstico inicial VMIA: identifique a causa antes de corrigir

Para evitar perda de dados, utilize uma sequência de verificação.

Fluxo técnico de diagnóstico

HD ou SSD antigo apresenta acesso negado

Confirmar reconhecimento do disco e preservar os dados

Verificar NTFS

SID, ACL, proprietário e herança

Verificar criptografia

EFS e BitLocker

Correlacionar mensagem de erro com evidências técnicas

Definir uma correção segura e específica

10. O que não fazer ao encontrar arquivos de outro HD com acesso negado

Alguns procedimentos frequentemente encontrados na Internet podem agravar o problema.

10.1. Não altere permissões de todo o disco sem necessidade

Aplicar controle total indiscriminadamente a uma unidade inteira pode modificar permissões importantes de arquivos do sistema, aplicativos e perfis antigos.

Isso também pode prejudicar a preservação das informações originais.

10.2. Não formate o disco

A formatação não é uma solução adequada quando o objetivo é recuperar arquivos existentes.

Ela pode provocar perda de dados.

10.3. Não confunda permissões com criptografia

Assumir a propriedade de um arquivo EFS não substitui a chave privada necessária à descriptografia.

Da mesma forma, permissões NTFS não desbloqueiam um volume BitLocker.

10.4. Não execute ferramentas de reparo indiscriminadamente

Se o disco apresentar ruídos, desconexões, erros de leitura ou sinais de falha física, priorize a preservação dos dados.

Ferramentas de reparo do sistema de arquivos podem modificar estruturas do volume e não devem ser a primeira medida em um disco potencialmente defeituoso.

Diagnóstico avançado com icacls, takeown, PowerShell, SID, ACL NTFS e EFS

Na primeira parte, explicamos por que arquivos armazenados em HDs e SSDs antigos podem apresentar mensagens de acesso negado quando conectados a outro computador com Windows 11.

Agora vamos aprofundar o diagnóstico das permissões NTFS, identificadores de segurança antigos, propriedade, herança e permissões efetivas.

Também veremos como utilizar ferramentas nativas do Windows para investigar problemas de acesso sem modificar indiscriminadamente as configurações de segurança.

O objetivo desta etapa é identificar exatamente qual regra impede o acesso e estabelecer um procedimento seguro para recuperar arquivos pessoais legítimos.

11. icacls: a principal ferramenta para diagnosticar permissões NTFS

O icacls.exe é um utilitário nativo do Windows que permite consultar, salvar, verificar e administrar listas de controle de acesso de arquivos e diretórios.

Ele é especialmente útil quando o Explorador de Arquivos apresenta mensagens como:

• Você não tem permissão para acessar esta pasta.
• Acesso negado.
• É necessário fornecer permissão de administrador.
• Você precisa de autorização para executar esta ação.
• Não foi possível enumerar os objetos no contêiner.

Essas mensagens podem ter causas diferentes, mesmo quando parecem indicar o mesmo problema.

11.1. Como consultar a ACL de uma pasta antiga

Considere um HD conectado como unidade E:.

A pasta afetada é:

E:\Users\Carlos\Documents

Abra o Prompt de Comando e execute:

icacls "E:\Users\Carlos\Documents"

Um resultado ilustrativo:

E:\Users\Carlos\Documents
    NT AUTHORITY\SYSTEM:(OI)(CI)(F)
    BUILTIN\Administrators:(OI)(CI)(F)
    S-1-5-21-123456789-987654321-456789123-1001:(OI)(CI)(M)

Nesse exemplo, existe uma entrada associada a um SID numérico.

Isso pode acontecer porque a conta original não está disponível na instalação atual do Windows.

Entretanto, a presença de um SID numérico não comprova, isoladamente, que ele seja responsável pelo acesso negado.

É necessário analisar todas as entradas relevantes.

11.2. Entendendo os códigos do icacls

Código	Significado
F	Controle total
M	Modificar
RX	Ler e executar
R	Leitura
W	Gravação
D	Excluir
OI	Herança para arquivos
CI	Herança para diretórios
IO	Entrada aplicável somente aos descendentes
I	Entrada herdada
NP	Não propagar herança

Uma entrada como:

BUILTIN\Administrators:(OI)(CI)(F)

indica uma permissão de controle total associada ao grupo Administradores, com indicadores de herança para arquivos e diretórios.

Isso não garante que todo processo iniciado por um administrador conseguirá acessar o conteúdo.

O resultado depende do token de segurança utilizado e de outras regras aplicáveis.

11.3. Como verificar a consistência das ACLs

O icacls possui uma opção para verificar inconsistências estruturais em descritores de segurança.

Exemplo:

icacls "E:\Dados" /verify

Esse comando pode identificar ACLs que não estão em formato canônico ou apresentam determinadas inconsistências.

Ele não é um verificador completo de corrupção NTFS.

Também não determina automaticamente se as permissões são adequadas ao usuário.

Para analisar uma estrutura maior, pode-se utilizar a opção /T, mas é recomendável começar por uma pasta pequena e conhecida.

12. Como preservar as permissões antes de qualquer alteração

Antes de modificar ACLs, registre o estado original.

Isso é especialmente importante quando o disco contém arquivos pessoais, dados empresariais ou estruturas antigas de perfis.

12.1. Salvando uma cópia das ACLs

Crie primeiro uma pasta de diagnóstico em outro volume saudável.

Por exemplo:

mkdir "C:\DiagnosticoVMIA"

Depois execute:

icacls "E:\Users\Carlos\Documents" /save "C:\DiagnosticoVMIA\acl-documentos.txt" /T /C

O comando salva informações das DACLs dos objetos percorridos.

A opção /T inclui subpastas e arquivos.

A opção /C permite continuar a operação mesmo quando determinados erros são encontrados.

Importante: o arquivo produzido pelo icacls /save não representa um backup completo de todos os atributos de segurança e criptografia.

Ele não substitui uma cópia integral dos dados, nem preserva as chaves EFS necessárias à descriptografia.

Também não deve ser tratado como uma imagem forense do disco.

12.2. Por que guardar as ACLs?

O registro permite comparar permissões antes e depois de uma intervenção.

Isso ajuda a identificar alterações indevidas e facilita a documentação do atendimento técnico.

Em um ambiente profissional, registre também:

• Caminho original da pasta.
• Unidade de origem.
• Data e horário da análise.
• Conta utilizada.
• Mensagem de erro apresentada.
• Comandos executados.
• Resultado de cada verificação.

13. SID órfão: quando a conta antiga não existe mais

Um SID órfão é uma expressão frequentemente utilizada para descrever um identificador de segurança que não pode mais ser associado a uma conta disponível.

Isso pode acontecer depois de:

• Reinstalação do Windows.
• Exclusão de uma conta local.
• Migração para outro computador.
• Remoção de um domínio.
• Perda de conectividade com um controlador de domínio.
• Restauração de dados provenientes de outro ambiente.

Entretanto, nem todo SID não resolvido representa uma conta definitivamente inexistente.

Em ambientes corporativos, a falha pode ser temporária.

13.1. Como identificar um SID antigo

Execute:

icacls "E:\Users\Carlos\Documents"

Se aparecer uma entrada numérica semelhante a:

S-1-5-21-...-1001

registre o identificador.

Depois consulte o SID da conta atual:

whoami /user

Compare os valores.

Se forem diferentes, isso demonstra que as identidades de segurança não são iguais.

Entretanto, a diferença não comprova que o usuário atual esteja sem acesso.

O acesso também pode ser concedido por grupos e outras entradas da ACL.

13.2. Como verificar a identidade atual pelo PowerShell

$Identidade = [System.Security.Principal.WindowsIdentity]::GetCurrent()

[PSCustomObject]@{
    Usuario = $Identidade.Name
    SID = $Identidade.User.Value
}

Esse comando apresenta o usuário e o SID associados ao processo atual.

Para examinar os grupos presentes no token:

whoami /groups

A análise deve considerar se os grupos relevantes estão habilitados.

14. Permissões efetivas: por que uma ACL aparentemente correta pode negar acesso?

Uma das dificuldades do diagnóstico NTFS é que a simples presença de uma permissão não garante acesso.

O Windows realiza uma avaliação baseada no descritor de segurança e no token do processo.

Essa avaliação considera diferentes fatores.

Entre eles estão:

• SID do usuário.
• Grupos presentes no token.
• Direitos solicitados.
• Entradas de permissão e negação.
• Ordem e aplicabilidade das ACEs.
• Nível de integridade.
• Privilégios administrativos.
• Restrições adicionais de segurança.

14.1. Exemplo de conflito entre permissões

Imagine uma pasta com as seguintes regras:

Identidade	Regra
Administradores	Controle total
Usuários	Leitura
Grupo específico	Negar gravação

Se o usuário pertence ao grupo cuja gravação foi negada, essa entrada pode impedir determinadas operações.

O resultado depende dos direitos efetivamente solicitados e da avaliação completa da ACL.

14.2. Como consultar o acesso efetivo pela interface gráfica

No Explorador:

1. Clique com o botão direito na pasta.
2. Abra Propriedades.
3. Entre em Segurança.
4. Selecione Avançadas.
5. Abra a guia Acesso Efetivo, quando disponível.
6. Selecione a identidade que deseja analisar.
7. Execute a avaliação.

A ferramenta pode ajudar a compreender quais direitos são concedidos à identidade selecionada.

Entretanto, ela não substitui testes reais quando existem mecanismos adicionais, como criptografia EFS, compartilhamentos de rede ou políticas de segurança.

14.3. Permissões NTFS e compartilhamento SMB

Se os arquivos estiverem em um compartilhamento de rede, a avaliação pode envolver permissões NTFS e permissões do compartilhamento.

Nesse cenário, o resultado pode ser diferente do acesso local ao mesmo diretório.

Por isso, não é correto atribuir automaticamente todo acesso negado em rede às ACLs NTFS.

15. takeown: o que significa assumir a propriedade de um arquivo?

O utilitário takeown.exe permite que usuários autorizados assumam a propriedade de arquivos ou diretórios, conforme os privilégios disponíveis.

Ele é frequentemente citado como solução para arquivos inacessíveis.

Entretanto, sua utilização exige cuidado.

Assumir a propriedade não equivale a conceder automaticamente todas as permissões de leitura e gravação.

Além disso, a alteração de propriedade modifica metadados de segurança.

15.1. Como consultar o proprietário antes de qualquer alteração

Utilize:

(Get-Acl -LiteralPath "E:\Users\Carlos\Documents").Owner

O comando informa a identidade registrada como proprietária.

Se aparecer um SID antigo, isso pode indicar que o diretório pertenceu a uma conta de outra instalação.

15.2. Quando o takeown pode ser considerado?

A alteração de propriedade pode ser apropriada em uma recuperação autorizada de dados pessoais não criptografados, depois que o técnico confirma que o bloqueio está relacionado ao descritor de segurança.

Antes de qualquer intervenção, é necessário:

1. Confirmar a autorização para acessar os dados.
2. Verificar se existe criptografia EFS.
3. Preservar os dados e registrar as permissões originais.
4. Delimitar a pasta que precisa de correção.
5. Avaliar o impacto sobre outros usuários e aplicativos.

Evite aplicar alterações recursivas à unidade inteira sem necessidade.

15.3. Por que o takeown não resolve arquivos EFS?

O EFS protege o conteúdo com criptografia.

A propriedade NTFS e a capacidade de descriptografar o arquivo são mecanismos distintos.

Mesmo que uma conta passe a ser proprietária, ela não recebe automaticamente a chave privada necessária à descriptografia.

16. Herança de permissões: como localizar a origem de uma regra

A herança permite que arquivos e subpastas recebam permissões de diretórios superiores.

Isso facilita a administração, mas também pode dificultar o diagnóstico quando existem exceções.

16.1. Como identificar entradas herdadas

Execute:

$Acl = Get-Acl -LiteralPath "E:\Users\Carlos\Documents"

$Acl.Access |
Select-Object IdentityReference,
              FileSystemRights,
              AccessControlType,
              IsInherited |
Format-Table -AutoSize

A coluna IsInherited indica se cada entrada foi herdada.

Um resultado True significa que a ACE foi herdada.

Um resultado False indica que a entrada é explícita naquele objeto.

16.2. Como verificar se a DACL está protegida contra herança

$Acl = Get-Acl -LiteralPath "E:\Users\Carlos\Documents"

$Acl.AreAccessRulesProtected

Se o resultado for True, a DACL está protegida contra herança.

Isso pode explicar por que uma subpasta possui regras diferentes da pasta superior.

16.3. Por que algumas pastas funcionam e outras não?

Considere:

E:\Dados
├── Fotos
├── Documentos
└── Projetos

A pasta Fotos pode herdar permissões de E:\Dados.

A pasta Documentos pode possuir permissões explícitas adicionais.

A pasta Projetos pode ter a herança protegida.

Consequentemente, o mesmo usuário pode conseguir abrir uma pasta e receber acesso negado em outra.

16.4. Cuidados ao modificar a herança

Alterações de herança podem afetar muitos arquivos.

Por isso, não recomendamos substituir indiscriminadamente permissões de objetos filhos.

O procedimento correto depende de identificar quais entradas devem permanecer e quais precisam ser ajustadas.

17. PowerShell: auditoria de permissões em múltiplas pastas

O PowerShell permite automatizar a coleta de informações sobre proprietários e ACLs.

Isso é útil quando um HD antigo contém várias pastas com comportamentos diferentes.

17.1. Script para listar proprietários de pastas

$PastaRaiz = "E:\Dados"

Get-ChildItem -LiteralPath $PastaRaiz -Directory -ErrorAction SilentlyContinue |
ForEach-Object {

    $Pasta = $_

    try {
        $Acl = Get-Acl -LiteralPath $Pasta.FullName

        [PSCustomObject]@{
            Pasta = $Pasta.FullName
            Proprietario = $Acl.Owner
            HerancaProtegida = $Acl.AreAccessRulesProtected
            Status = "Consultado"
        }
    }
    catch {
        [PSCustomObject]@{
            Pasta = $Pasta.FullName
            Proprietario = ""
            HerancaProtegida = ""
            Status = $_.Exception.Message
        }
    }

} | Format-Table -AutoSize

O script consulta apenas as subpastas imediatas do diretório informado.

Ele não modifica permissões.

17.2. Como interpretar os resultados

Se várias pastas apresentarem proprietários diferentes, isso pode indicar que os dados foram criados por contas distintas.

Se algumas apresentarem herança protegida, será necessário examinar suas entradas explícitas.

Se ocorrer acesso negado durante a consulta, registre a falha.

Não é recomendado tentar corrigir automaticamente todas as pastas com base apenas nesse resultado.

18. EFS: diagnóstico avançado antes de alterar permissões

O Encrypting File System é um dos pontos mais importantes na recuperação de arquivos de outro computador.

O EFS utiliza criptografia para proteger o conteúdo de arquivos armazenados em NTFS.

18.1. Como verificar se um arquivo utiliza EFS

Execute:

cipher /c "E:\Users\Carlos\Documents\arquivo.docx"

O comando permite consultar informações de criptografia relacionadas ao arquivo.

Se houver criptografia EFS, o resultado poderá apresentar informações sobre certificados associados.

18.2. O que acontece quando a chave privada não está disponível?

O Windows pode reconhecer o arquivo, apresentar seu nome e permitir determinadas operações de metadados.

Entretanto, a leitura do conteúdo pode continuar indisponível.

Isso acontece porque as permissões NTFS não substituem as chaves criptográficas.

18.3. Como diferenciar EFS de ACL?

Característica	Problema de ACL	Problema de EFS
Arquivo aparece no Explorador	Sim	Sim
Pode apresentar acesso negado	Sim	Sim
Depende de permissões NTFS	Sim	Também existem permissões
Depende de chave privada EFS	Não	Sim
Alterar proprietário pode resolver sozinho	Não necessariamente	Não
Exige investigação criptográfica	Normalmente não	Sim

18.4. Por que preservar a instalação antiga?

Se o computador original ainda funciona, ele pode conter o certificado e a chave privada necessários.

Em situações legítimas de recuperação, preservar esse ambiente pode ser essencial.

Não formate a instalação antiga antes de verificar a disponibilidade das credenciais criptográficas e dos backups.

19. Perfis antigos: por que a pasta Users exige atenção especial?

Pastas de perfis de usuário podem conter permissões específicas.

Entre elas estão:

E:\Users\Carlos
E:\Users\Carlos\AppData
E:\Users\Carlos\Documents
E:\Users\Carlos\Desktop

O diretório AppData contém configurações e dados de aplicativos.

Ele não deve ser tratado como uma pasta comum de documentos pessoais.

19.1. Por que não modificar todo o perfil?

Alterações indiscriminadas podem afetar:

• Configurações de aplicativos.
• Dados protegidos por usuário.
• Arquivos de perfil.
• Permissões de serviços.
• Componentes de software.
• Estruturas utilizadas pelo Windows.

Além disso, algumas informações podem depender de mecanismos criptográficos associados à conta original.

19.2. Qual abordagem é mais segura?

Quando o objetivo é recuperar documentos pessoais, priorize as pastas que realmente contêm os dados necessários.

Evite modificar diretórios de sistema e configurações de aplicativos sem uma justificativa técnica.

20. Como diferenciar acesso negado de falha física no HD

Nem todo problema de leitura é causado por permissões.

Um disco antigo pode apresentar falhas físicas ou inconsistências no sistema de arquivos.

20.1. Sintomas que exigem investigação de hardware

• Disco desconecta durante a leitura.
• Arquivos apresentam erros de entrada e saída.
• Pastas demoram excessivamente para abrir.
• O Windows apresenta erros de leitura.
• O dispositivo desaparece do Explorador.
• Existem sinais de falha física.

Nesses casos, priorize a preservação dos dados.

Evite executar reparos que modifiquem o sistema de arquivos antes de avaliar a condição do dispositivo.

20.2. Como identificar o sistema de arquivos

Execute:

Get-Volume |
Select-Object DriveLetter,FileSystem,HealthStatus,OperationalStatus

O comando apresenta informações dos volumes reconhecidos pelo Windows.

Entretanto, o estado de saúde apresentado não substitui uma avaliação completa do hardware.

21. Tabela de diagnóstico técnico por causa

Sintoma	Possível causa	Verificação
Pasta solicita permissão de administrador	ACL ou propriedade	icacls / Get-Acl
SID numérico aparece nas permissões	Identidade antiga não resolvida	whoami /user
Algumas subpastas não abrem	Herança ou ACE explícita	Get-Acl
Usuário administrador recebe acesso negado	Token, ACL ou outra restrição	whoami /groups
Arquivo EFS não abre	Ausência de chave privada	cipher /c
Disco solicita chave de recuperação	BitLocker	Estado do volume
Arquivos apresentam erro de leitura	Hardware ou sistema de arquivos	Diagnóstico do disco
Pasta de perfil antigo apresenta restrições	ACL e dados protegidos	Análise direcionada

ACL NTFS avançadas, auditoria de segurança, Process Monitor, UAC, junctions e criptografia EFS

Nas duas primeiras partes deste guia, explicamos por que arquivos armazenados em HDs e SSDs antigos podem apresentar acesso negado depois de serem conectados a outro computador com Windows 11.

Também analisamos os identificadores SID, as permissões NTFS, a propriedade de arquivos, a herança e os riscos de alterar configurações sem verificar previamente a existência de criptografia.

Agora vamos aprofundar o diagnóstico utilizando mecanismos internos de segurança do Windows.

O objetivo é descobrir qual operação foi negada, qual identidade tentou executá-la e qual componente pode estar impedindo o acesso, sem comprometer a integridade dos dados.

23. ACL NTFS avançadas: como o Windows realmente decide quem pode acessar um arquivo

O NTFS utiliza descritores de segurança para controlar o acesso a arquivos e diretórios.

Esses descritores podem conter diferentes informações, incluindo:

• Proprietário do objeto.
• Grupo primário.
• DACL — Discretionary Access Control List.
• SACL — System Access Control List.
• Informações adicionais relacionadas ao controle de acesso.

A DACL determina quais acessos são permitidos ou negados a determinadas identidades.

A SACL pode conter informações utilizadas para auditoria e controle de integridade.

23.1. Como funciona uma ACE?

Uma Access Control Entry, ou ACE, é uma entrada de controle de acesso.

Ela pode identificar um usuário ou grupo e definir direitos específicos.

Entre os tipos mais conhecidos estão:

Allow: permite determinados direitos.

Deny: nega determinados direitos.

Entretanto, a avaliação não consiste simplesmente em procurar uma entrada Allow ou Deny.

O Windows considera os direitos solicitados, as identidades presentes no token e a estrutura da lista de controle de acesso.

23.2. Exemplo de permissões conflitantes

Imagine uma pasta com as seguintes regras:

Identidade	Tipo	Direito
Administradores	Allow	Controle total
Usuários	Allow	Leitura
Grupo Projetos	Deny	Gravação
Carlos	Allow	Modificar

Se Carlos pertence ao grupo Projetos, a regra de negação pode impedir operações de gravação.

Isso depende da aplicabilidade das entradas e dos direitos solicitados.

Uma permissão Allow não deve ser interpretada isoladamente.

23.3. Ordem das entradas na DACL

O Windows utiliza uma ordem canônica para entradas de controle de acesso.

De forma geral, entradas explícitas de negação aparecem antes de entradas explícitas de permissão, seguidas pelas entradas herdadas conforme as regras de herança.

A ordem pode influenciar a avaliação dos direitos.

Por isso, ferramentas administrativas devem preservar a estrutura adequada da ACL.

O utilitário icacls permite verificar determinadas inconsistências:

icacls "E:\Dados" /verify

Esse comando não altera as permissões.

Ele também não determina se uma ACL está adequada à finalidade da pasta.

24. Permissões especiais NTFS: por que leitura e gravação não explicam tudo?

As permissões apresentadas na interface gráfica do Windows são agrupamentos de direitos mais específicos.

Por exemplo, a permissão Modificar reúne diferentes operações.

Entretanto, determinadas situações exigem analisar os direitos individualmente.

24.1. Principais direitos especiais

Direito	Função
ReadData	Ler dados de um arquivo
ListDirectory	Listar conteúdo de diretórios
WriteData	Gravar dados em arquivos
CreateFiles	Criar arquivos em diretórios
AppendData	Acrescentar dados
CreateDirectories	Criar subdiretórios
Delete	Excluir o objeto
DeleteSubdirectoriesAndFiles	Excluir descendentes
ReadAttributes	Consultar atributos
WriteAttributes	Modificar atributos
ReadPermissions	Consultar permissões
ChangePermissions	Alterar DACL
TakeOwnership	Assumir propriedade, conforme autorização
ExecuteFile	Executar arquivo
Traverse	Atravessar diretórios

Esses direitos ajudam a explicar situações aparentemente contraditórias.

Um usuário pode conseguir abrir um documento, mas não salvar alterações.

Também pode conseguir criar arquivos em uma pasta, mas não excluir arquivos existentes.

24.2. Por que é possível criar um arquivo, mas não excluí-lo?

Criar e excluir são operações distintas.

A exclusão pode depender do direito DELETE sobre o objeto ou de direitos apropriados no diretório pai.

Consequentemente, uma ACL pode permitir criação e impedir exclusão.

Isso não significa necessariamente que o NTFS esteja corrompido.

24.3. Como examinar direitos especiais com PowerShell

Execute:

$Acl = Get-Acl -LiteralPath "E:\Dados"

$Acl.Access |
Select-Object IdentityReference,
              FileSystemRights,
              AccessControlType,
              IsInherited |
Format-Table -AutoSize

O campo FileSystemRights apresenta os direitos associados às entradas.

Algumas combinações podem aparecer como valores numéricos ou conjuntos de permissões.

Nesses casos, é necessário interpretar as máscaras de acesso correspondentes.

25. SID, grupos e tokens: por que ser administrador não garante acesso?

O Windows utiliza tokens de acesso para representar o contexto de segurança dos processos.

O token contém informações como:

• SID do usuário.
• Grupos de segurança.
• Privilégios.
• Nível de integridade.
• Atributos de grupos.
• Informações relacionadas à elevação.

Quando um aplicativo tenta abrir um arquivo, o Windows avalia a solicitação considerando esse contexto.

25.1. UAC e tokens administrativos

O Controle de Conta de Usuário, conhecido como UAC, permite que contas administrativas executem processos com privilégios limitados em situações normais.

Isso significa que um usuário pertencente ao grupo Administradores pode iniciar um aplicativo sem elevação.

Nesse contexto, determinadas permissões associadas ao grupo Administradores podem não estar disponíveis da mesma forma que em um processo elevado.

25.2. Como verificar os grupos e privilégios do processo

Execute:

whoami /all

O comando apresenta informações do token atual.

Entre elas estão grupos, privilégios e nível de integridade.

Para consultar somente os privilégios:

whoami /priv

O resultado pode apresentar privilégios como:

• SeBackupPrivilege.
• SeRestorePrivilege.
• SeTakeOwnershipPrivilege.
• SeSecurityPrivilege.

A presença de um privilégio não significa que ele esteja habilitado ou que qualquer aplicativo possa utilizá-lo automaticamente.

25.3. O que acontece quando um programa é executado como administrador?

A elevação pode disponibilizar um token com direitos administrativos adicionais.

Entretanto, ela não elimina automaticamente todas as restrições de acesso.

Um processo elevado ainda pode encontrar:

• Entradas de negação aplicáveis.
• Restrições de integridade.
• Arquivos criptografados com EFS.
• Volumes BitLocker bloqueados.
• Problemas de compartilhamento.
• Restrições impostas por outros mecanismos de segurança.

Portanto, executar um aplicativo como administrador não deve ser utilizado como solução universal.

26. Auditoria de segurança: como identificar tentativas de acesso negado

O Windows possui mecanismos de auditoria que podem registrar determinadas operações realizadas sobre arquivos e diretórios.

Esses registros ajudam a identificar qual processo tentou acessar um objeto e quais direitos estavam envolvidos.

Entretanto, a geração dos eventos depende da configuração das políticas de auditoria e das SACLs correspondentes.

26.1. Eventos 4656 e 4663

Dois eventos importantes são:

Evento	Significado
4656	Uma operação solicitou um identificador de acesso a um objeto
4663	Uma tentativa de acesso a um objeto foi registrada

O evento 4656 pode registrar solicitações de acesso, incluindo falhas quando a auditoria correspondente está configurada.

O evento 4663 registra operações de acesso auditadas, mas não deve ser interpretado automaticamente como evidência de acesso negado.

26.2. Onde encontrar os eventos?

Abra:

eventvwr.msc

Depois navegue até:

Logs do Windows → Segurança

Procure eventos relacionados ao horário em que o problema ocorreu.

A ausência de eventos não comprova que não houve tentativa de acesso.

Pode significar que a auditoria não estava configurada para registrar aquela operação.

26.3. Como consultar os eventos com PowerShell

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4656,4663
    StartTime = (Get-Date).AddHours(-2)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message |
Format-List

O comando consulta eventos das últimas duas horas.

Em computadores com muitos eventos, o resultado pode ser extenso.

Para uma investigação precisa, compare o horário, o caminho do arquivo e a identidade envolvida.

26.4. Por que a auditoria precisa ser configurada?

O Windows não registra automaticamente todas as operações de acesso a arquivos.

A auditoria de objetos depende das políticas correspondentes.

Além disso, uma SACL pode definir quais operações devem ser auditadas.

Em ambientes corporativos, essas configurações podem ser administradas centralmente.

Não é recomendado habilitar auditoria indiscriminadamente em todo o disco, pois isso pode gerar grande volume de eventos.

27. Sysinternals Process Monitor: descobrindo qual operação recebeu ACCESS DENIED

O Process Monitor, ou ProcMon, é uma ferramenta avançada da Microsoft Sysinternals.

Ele permite observar operações relacionadas a arquivos, Registro, processos e threads.

É especialmente útil quando o Windows apresenta acesso negado, mas não informa claramente qual operação falhou.

27.1. Como utilizar o Process Monitor

Obtenha a ferramenta pelo site oficial:Microsoft Sysinternals — Process Monitor

Depois:

1. Execute o Process Monitor com as permissões necessárias.
2. Interrompa a captura inicial.
3. Limpe os eventos apresentados.
4. Configure filtros relacionados ao arquivo ou processo.
5. Inicie uma nova captura.
6. Reproduza o problema.
7. Interrompa a captura.
8. Examine os eventos relevantes.

27.2. Como filtrar eventos de acesso negado

No menu de filtros, configure uma condição semelhante a:

Result is ACCESS DENIED

Também é possível filtrar pelo caminho do arquivo ou pelo nome do processo.

Por exemplo:

Path begins with E:\Users\Carlos

Esses filtros ajudam a reduzir a quantidade de eventos apresentados.

27.3. Como interpretar os resultados

Imagine um aplicativo tentando abrir:

E:\Users\Carlos\Documents\Relatorio.docx

O ProcMon registra:

Operation: CreateFile
Result: ACCESS DENIED

Isso indica que a tentativa de abertura do objeto foi recusada.

Entretanto, o resultado não identifica automaticamente a ACE responsável.

Também não comprova, isoladamente, que o problema está relacionado a permissões NTFS.

É necessário correlacionar a operação com o token do processo, a ACL e outros mecanismos aplicáveis.

27.4. Atenção aos eventos NAME NOT FOUND

O resultado NAME NOT FOUND indica que determinado objeto não foi localizado.

Aplicativos frequentemente procuram arquivos ou chaves inexistentes como parte de seu funcionamento normal.

Portanto, encontrar esse resultado não significa necessariamente que existe um defeito.

28. Reparse points e junctions: quando a pasta não aponta para onde parece

O NTFS possui mecanismos que permitem criar referências especiais para outros caminhos.

Entre eles estão os reparse points.

Junctions e links simbólicos são exemplos conhecidos.

Esses mecanismos podem provocar confusão durante a recuperação de perfis antigos.

28.1. O que é uma junction?

Uma junction é um tipo de referência de diretório que redireciona o acesso para outro caminho.

Ela pode ser utilizada por mecanismos de compatibilidade e organização de diretórios.

Em perfis do Windows, algumas junctions existem para manter compatibilidade com aplicativos antigos.

28.2. Por que junctions podem apresentar acesso negado?

Determinadas junctions de compatibilidade possuem permissões específicas para impedir navegação indevida ou recursão.

Por exemplo, um aplicativo antigo pode tentar acessar um caminho que foi substituído por uma estrutura moderna.

O Windows pode apresentar acesso negado para determinadas operações.

Isso não significa necessariamente que os documentos pessoais estejam inacessíveis.

28.3. Como identificar reparse points

Execute:

dir /al "E:\Users\Carlos"

O parâmetro /al permite listar entradas com o atributo de reparse point, como links e junctions, conforme o contexto.

No PowerShell:

Get-ChildItem -LiteralPath "E:\Users\Carlos" -Force |
Where-Object { $_.Attributes -band [IO.FileAttributes]::ReparsePoint } |
Select-Object Name,FullName,LinkType,Target

A disponibilidade de determinadas propriedades depende da versão do PowerShell e do tipo de objeto.

28.4. Por que não remover junctions indiscriminadamente?

Junctions podem fazer parte da estrutura esperada por aplicativos e pelo sistema.

Sua remoção pode provocar problemas adicionais.

Além disso, uma operação recursiva mal planejada pode atravessar referências para outros diretórios.

Por isso, ferramentas de cópia e auditoria devem ser configuradas com atenção ao tratamento de reparse points.

29. EFS avançado: certificados, chaves privadas e recuperação

O Encrypting File System protege o conteúdo de arquivos utilizando criptografia.

Diferentemente das permissões NTFS, o EFS depende de material criptográfico.

29.1. Como verificar informações EFS

Execute:

cipher /c "E:\Users\Carlos\Documents\Arquivo.docx"

O comando permite consultar informações de criptografia relacionadas ao arquivo.

Se o arquivo estiver protegido por EFS, poderão ser apresentadas informações sobre os certificados envolvidos.

29.2. Por que a chave privada é importante?

O EFS utiliza mecanismos criptográficos que permitem proteger a chave utilizada para criptografar o conteúdo.

A recuperação depende da disponibilidade das credenciais adequadas.

Se a chave privada necessária não estiver disponível, alterar permissões NTFS não será suficiente.

29.3. Onde os certificados podem estar armazenados?

Em instalações Windows, certificados associados ao usuário podem ser encontrados no repositório pessoal.

Para consultar certificados do usuário atual:

certutil -user -store My

Esse comando lista certificados do repositório pessoal do usuário atual.

Ele não garante que a chave privada EFS necessária esteja disponível.

Também não recupera automaticamente certificados de uma instalação antiga.

29.4. Como verificar se existe uma chave privada associada?

A análise deve considerar as informações apresentadas pelo repositório de certificados e pelo provedor criptográfico.

A presença de um certificado público não significa que sua chave privada esteja disponível.

Por isso, backups EFS precisam incluir o material criptográfico necessário à recuperação.

29.5. O que fazer quando o Windows antigo ainda funciona?

Se a instalação original ainda estiver acessível, preserve-a.

Ela pode conter certificados e chaves necessários.

Antes de reinstalar ou formatar o sistema, verifique a existência de backups adequados.

Em ambientes corporativos, também pode existir um agente de recuperação de dados previamente configurado.

30. Recuperação segura: como planejar uma intervenção sem comprometer os dados

Antes de modificar permissões, defina o objetivo da recuperação.

Por exemplo:

• Recuperar documentos pessoais.
• Copiar fotografias.
• Restaurar projetos.
• Acessar dados de aplicativos.
• Migrar um perfil antigo.
• Preservar arquivos para análise técnica.

Cada cenário exige cuidados diferentes.

30.1. Priorize os arquivos necessários

Quando o objetivo é recuperar documentos pessoais, evite modificar indiscriminadamente todo o volume.

Comece pelas pastas relevantes.

Isso reduz o risco de afetar estruturas do Windows e aplicativos antigos.

30.2. Preserve o estado original

Sempre que possível, mantenha uma cópia de segurança dos dados e registre as ACLs.

Em discos com suspeita de falha física, a preservação deve ocorrer antes de operações que provoquem muitas leituras ou modificações.

30.3. Diferencie os mecanismos de proteção

Mecanismo	O que controla	Consideração principal
ACL NTFS	Direitos de acesso	Analisar DACL e token
Propriedade	Administração de permissões	Não concede leitura automática
UAC	Elevação administrativa	Não elimina todas as restrições
EFS	Criptografia de arquivos	Exige material criptográfico
BitLocker	Criptografia de volumes	Exige desbloqueio do volume
Junctions	Redirecionamento de caminhos	Pode provocar confusão em operações recursivas
Auditoria	Registro de operações	Depende de políticas e SACL

31. Exemplo prático: diagnóstico de um HD antigo

Considere um computador com Windows 11 no qual um HD antigo foi conectado como unidade E:.

O usuário tenta abrir:

E:\Users\Carlos\Documents

O Windows apresenta acesso negado.

Etapa 1 — Verificar a identidade atual

whoami /user

Registre o SID apresentado.

Etapa 2 — Consultar as permissões

icacls "E:\Users\Carlos\Documents"

Examine as entradas da ACL.

Etapa 3 — Consultar o proprietário

(Get-Acl -LiteralPath "E:\Users\Carlos\Documents").Owner

Verifique se a identidade pertence à instalação antiga.

Etapa 4 — Examinar a herança

(Get-Acl -LiteralPath "E:\Users\Carlos\Documents").AreAccessRulesProtected

Registre o resultado.

Etapa 5 — Investigar criptografia

Se houver arquivos específicos inacessíveis, consulte o estado EFS:

cipher /c "E:\Users\Carlos\Documents\Arquivo.docx"

Etapa 6 — Correlacionar com eventos

Se necessário, utilize o Process Monitor e os registros de auditoria para identificar a operação recusada.

Etapa 7 — Definir a correção

Somente depois de reunir as evidências, determine se é necessário corrigir uma ACL, recuperar credenciais criptográficas ou investigar outro mecanismo.

32. Erros técnicos que devem ser evitados

Erro 1 — Considerar todo SID numérico como defeito.

Um SID não resolvido pode representar uma identidade antiga, mas sua presença não comprova que ele causa o bloqueio.

Erro 2 — Aplicar controle total a todos os usuários.

Permissões excessivamente amplas podem expor dados e comprometer a segurança.

Erro 3 — Alterar a propriedade de todo o disco.

Isso pode modificar estruturas que não precisam de intervenção.

Erro 4 — Confundir EFS com NTFS.

Permissões não substituem chaves criptográficas.

Erro 5 — Interpretar qualquer ACCESS DENIED do ProcMon como falha de ACL.

Outros mecanismos também podem impedir operações.

Erro 6 — Ignorar junctions e reparse points.

Operações recursivas podem produzir resultados inesperados quando existem redirecionamentos.

Erro 7 — Executar reparos em um disco fisicamente instável.

A preservação dos dados deve ser priorizada quando existem sinais de falha.

Explicamos o funcionamento dos identificadores SID, das permissões NTFS, das listas de controle de acesso (ACL), da propriedade dos arquivos, da herança e dos mecanismos de criptografia EFS e BitLocker.

Também exploramos ferramentas como icacls, takeown, PowerShell, Process Monitor e Visualizador de Eventos.

Agora vamos reunir essas informações em procedimentos de correção, diferenciando situações que podem ser resolvidas com ajustes pontuais de permissões daquelas que exigem recuperação de chaves criptográficas ou diagnóstico do hardware.

O princípio central é simples: não existe um único comando capaz de resolver todos os problemas de acesso negado sem riscos. A solução depende da causa identificada.

33. Antes de corrigir: confirme se o problema realmente envolve permissões NTFS

Um HD antigo pode apresentar diferentes problemas que produzem mensagens semelhantes.

Antes de executar qualquer comando de alteração, identifique o cenário.

Sintoma	Causa provável	Próxima verificação
Pasta de usuário antigo apresenta acesso negado	ACL ou SID antigo	icacls
Conta atual não consegue modificar arquivos	Permissões insuficientes	Get-Acl
Administrador consegue acessar somente após elevação	UAC ou token restrito	whoami /groups
Arquivo permanece inacessível após ajustar ACL	EFS ou outra proteção	cipher /c
Volume solicita chave de recuperação	BitLocker	manage-bde -status
Pasta antiga aponta para outro caminho	Junction ou link simbólico	dir /al
Disco desconecta ou apresenta erros de leitura	Possível falha física	Diagnóstico de armazenamento
Arquivos apresentam ícone de cadeado, mas abrem normalmente	Indicador visual ou permissão restrita	Verificar acesso efetivo

A mensagem exata do Windows, o caminho do arquivo e o contexto da operação ajudam a direcionar o diagnóstico.

33.1. Primeiro procedimento: preservar os dados

Se o disco estiver saudável e os arquivos puderem ser copiados por um processo autorizado, preserve uma cópia em outro dispositivo.

Se houver suspeita de falha física, evite operações que provoquem gravações ou verificações intensivas no disco original.

Em situações de recuperação profissional, pode ser mais adequado trabalhar sobre uma imagem do dispositivo.

34. Solução 1 — Corrigir acesso negado causado por permissões NTFS antigas

Esse cenário costuma ocorrer quando o disco pertenceu a outra instalação do Windows.

O sistema atual reconhece a unidade, mas a pasta possui permissões associadas ao usuário antigo.

34.1. Identifique a pasta afetada

Exemplo:

E:\Users\Carlos\Documents

Não comece modificando toda a unidade E:.

A intervenção deve ser limitada aos diretórios que realmente precisam de acesso.

34.2. Consulte as permissões atuais

Abra o Prompt de Comando:

icacls "E:\Users\Carlos\Documents"

Observe:

• Identidades listadas.
• Permissões concedidas.
• Entradas de negação.
• Indicadores de herança.
• SIDs que não podem ser resolvidos.

34.3. Registre a ACL original

Antes de alterar permissões:

mkdir "C:\DiagnosticoVMIA"

Depois:

icacls "E:\Users\Carlos\Documents" /save "C:\DiagnosticoVMIA\acl-original.txt" /T /C

O arquivo registra as DACLs dos objetos percorridos.

Ele não substitui um backup completo e não preserva as chaves EFS.

34.4. Conceda somente os direitos necessários

Se o diagnóstico confirmar que a conta atual precisa de acesso a uma pasta pessoal não criptografada, é possível adicionar uma entrada específica à ACL.

Por exemplo, em um Prompt de Comando elevado:

icacls "E:\Users\Carlos\Documents" /grant "%USERDOMAIN%\%USERNAME%:(OI)(CI)RX"

Esse exemplo concede direitos de leitura e execução à conta indicada, com herança para arquivos e subdiretórios quando aplicável.

Ele não altera automaticamente todas as ACLs já existentes nos arquivos filhos. Objetos com herança desativada podem continuar inacessíveis.

Se for necessário modificar os documentos, a permissão M poderá ser considerada após avaliar o impacto.

Evite conceder controle total quando leitura ou modificação forem suficientes.

Atenção: %USERDOMAIN%\%USERNAME% identifica a conta do ambiente do Prompt de Comando. Se o terminal elevado estiver executando sob outra conta administrativa, confirme a identidade antes de aplicar a alteração.

35. Solução 2 — Assumir a propriedade quando o proprietário antigo impede a administração da ACL

Em alguns casos, o usuário atual não consegue modificar a DACL porque o proprietário pertence à instalação antiga.

Nesse cenário, pode ser necessário assumir a propriedade do objeto.

35.1. Verifique o proprietário atual

No PowerShell:

(Get-Acl -LiteralPath "E:\Users\Carlos\Documents").Owner

Se aparecer um SID antigo, registre o valor.

35.2. Como funciona o takeown

O utilitário takeown permite assumir a propriedade quando o processo possui autorização e privilégios apropriados.

Para uma pasta específica:

takeown /F "E:\Users\Carlos\Documents"

Esse comando solicita a alteração de propriedade do diretório indicado.

Ele não concede automaticamente acesso completo aos arquivos.

Também não altera recursivamente todos os descendentes sem opções adicionais.

35.3. Quando utilizar a opção recursiva?

A opção /R permite processar descendentes.

Entretanto, não a utilize automaticamente em perfis completos ou na raiz do disco.

Antes de considerar uma alteração recursiva, verifique:

• Se os dados pertencem legitimamente ao usuário atendido.
• Se existem arquivos EFS.
• Se há junctions ou links simbólicos.
• Se as permissões originais foram documentadas.
• Se a alteração é realmente necessária.

Após assumir a propriedade, examine novamente a ACL e conceda somente os direitos necessários.

35.4. Quando não utilizar takeown?

Não utilize esse procedimento como tentativa de resolver:

• Volume BitLocker bloqueado.
• Arquivos EFS sem chave privada.
• Disco com falha física.
• Arquivos de terceiros sem autorização.
• Diretórios de sistema cuja finalidade não foi identificada.

36. Solução 3 — Corrigir problemas causados por SID antigo ou órfão

Um SID não resolvido pode aparecer depois de reinstalar o Windows ou conectar um disco utilizado em outro computador.

Exemplo ilustrativo:

S-1-5-21-123456789-987654321-456789123-1001

O fato de esse identificador não ser reconhecido pelo computador atual não significa que ele deva ser removido imediatamente.

36.1. Verifique a identidade atual

whoami /user

Compare o SID atual com os identificadores registrados na ACL.

36.2. Verifique os grupos

whoami /groups

O acesso pode ser concedido por grupos mesmo quando o SID individual antigo não corresponde ao usuário atual.

36.3. Qual é a correção adequada?

Quando a causa for uma ACL que concede acesso exclusivamente à identidade antiga, a solução pode ser adicionar uma permissão específica para a conta atual.

A remoção do SID antigo não é obrigatória.

Em muitos casos, preservar a entrada original é preferível, especialmente quando o disco poderá voltar ao computador anterior.

Evite remover SIDs em massa. Em ambientes corporativos, identificadores aparentemente desconhecidos podem pertencer a contas de domínio temporariamente indisponíveis.

37. Solução 4 — Corrigir herança de permissões sem comprometer outras pastas

A herança permite que diretórios recebam permissões de seus diretórios superiores.

Quando uma subpasta possui herança protegida, ela pode apresentar comportamento diferente das demais.

37.1. Verifique a herança

$Acl = Get-Acl -LiteralPath "E:\Dados\Projetos"

$Acl.AreAccessRulesProtected

Se o resultado for True, a DACL está protegida contra herança.

37.2. Examine as entradas

$Acl.Access |
Select-Object IdentityReference,
              FileSystemRights,
              AccessControlType,
              IsInherited |
Format-Table -AutoSize

Verifique se existem permissões explícitas ou regras de negação.

37.3. Quando restaurar a herança?

A restauração pode ser apropriada quando o diagnóstico confirma que a pasta deveria seguir as permissões do diretório superior.

Entretanto, antes de ativá-la, determine se existem regras explícitas que precisam ser preservadas.

A interface gráfica do Windows permite examinar essas opções em:

Propriedades → Segurança → Avançadas

Evite substituir indiscriminadamente as permissões de todos os objetos filhos.

Essa operação pode remover configurações específicas necessárias a determinados arquivos.

38. Solução 5 — Acesso negado mesmo sendo administrador: investigue o UAC

O Windows 11 utiliza o Controle de Conta de Usuário para separar processos comuns de operações administrativas.

Uma conta pertencente ao grupo Administradores pode executar aplicativos com um token restrito.

Isso explica por que determinados programas apresentam acesso negado, enquanto ferramentas elevadas conseguem consultar o mesmo diretório.

38.1. Verifique o token atual

whoami /all

Examine os grupos e privilégios.

38.2. Teste a operação em contexto administrativo autorizado

Quando apropriado, compare o comportamento de uma ferramenta executada normalmente com o de uma instância elevada.

Entretanto, não utilize a elevação como solução permanente para todos os aplicativos.

O ideal é corrigir a permissão específica que está impedindo a operação legítima.

38.3. Não desative o UAC

Desativar o Controle de Conta de Usuário reduz proteções importantes do Windows.

Esse procedimento não é necessário para recuperar documentos de um HD antigo.

39. Solução 6 — Arquivos criptografados com EFS: recuperar a chave, não apenas a permissão

O EFS é um mecanismo de criptografia de arquivos.

Se um documento estiver criptografado com EFS, modificar a ACL ou assumir a propriedade não garante acesso ao conteúdo.

39.1. Verifique se existe criptografia

cipher /c "E:\Users\Carlos\Documents\Arquivo.docx"

O comando consulta informações relacionadas à criptografia.

39.2. Verifique os certificados disponíveis

certutil -user -store My

O comando consulta o repositório pessoal de certificados do usuário atual.

Entretanto, encontrar um certificado não comprova que sua chave privada esteja disponível.

39.3. Como recuperar o acesso?

A recuperação legítima depende da disponibilidade do material criptográfico apropriado.

As possibilidades incluem:

• Backup do certificado EFS acompanhado da chave privada.
• Instalação original ainda acessível com as credenciais necessárias.
• Agente de recuperação de dados previamente configurado.
• Backup dos arquivos em formato descriptografado.

Se o computador original ainda funciona, preserve a instalação e verifique a possibilidade de exportar o certificado EFS com a chave privada por meio das ferramentas oficiais do Windows.

Sem as chaves apropriadas, a recuperação pode ser inviável.

Nunca prometa que takeown ou icacls conseguirá descriptografar arquivos EFS.

40. Solução 7 — HD protegido com BitLocker: verifique o estado do volume

O BitLocker protege volumes inteiros.

Quando um volume está bloqueado, o Windows pode solicitar uma chave de recuperação.

Isso é diferente de uma pasta NTFS com permissões antigas.

40.1. Como consultar o estado do BitLocker

Abra um Prompt de Comando elevado e execute:

manage-bde -status E:

O comando apresenta informações sobre o estado de proteção do volume, quando disponíveis.

40.2. Como recuperar o acesso?

O volume deve ser desbloqueado utilizando as credenciais ou a chave de recuperação legítima correspondente.

Dependendo de como o BitLocker foi configurado, a chave pode estar armazenada na conta Microsoft, no ambiente corporativo ou em um backup realizado anteriormente.

Não formate a unidade caso os arquivos ainda precisem ser recuperados.

Alterar permissões NTFS não substitui o desbloqueio do BitLocker.

41. Solução 8 — Junctions e reparse points: evite corrigir permissões no caminho errado

Algumas pastas de perfis antigos utilizam junctions ou outros tipos de reparse points.

Essas estruturas podem redirecionar o acesso para outros diretórios.

41.1. Como identificar junctions

dir /al "E:\Users\Carlos"

Examine as entradas apresentadas.

41.2. Por que isso importa?

Determinadas junctions de compatibilidade possuem permissões específicas.

Elas podem apresentar acesso negado mesmo quando as pastas reais continuam acessíveis.

Por exemplo, uma junction antiga pode apontar para um diretório moderno de configurações do usuário.

Nesse caso, a solução não é necessariamente modificar a ACL da junction.

É preferível localizar o diretório real que contém os dados.

41.3. Evite operações recursivas indiscriminadas

Ferramentas que percorrem estruturas de diretórios precisam considerar a existência de reparse points.

Antes de executar cópias ou alterações recursivas, confirme se o procedimento atravessará links ou junctions.

Isso ajuda a evitar processamento repetido, caminhos inesperados e alterações fora do escopo planejado.

42. Como recuperar documentos pessoais de um HD antigo com segurança

Quando o objetivo é recuperar fotografias, documentos e projetos pessoais, a estratégia deve priorizar a preservação dos dados.

42.1. Identifique as pastas necessárias

Exemplos:

E:\Users\Carlos\Documents
E:\Users\Carlos\Desktop
E:\Users\Carlos\Pictures
E:\Users\Carlos\Videos

Os nomes podem variar conforme o idioma e a configuração da instalação antiga.

Também pode haver redirecionamento de pastas para OneDrive ou outras unidades.

42.2. Confirme que o disco está saudável

Se o disco apresentar sinais de falha física, interrompa tentativas repetitivas de acesso.

A recuperação deve priorizar uma cópia adequada dos dados.

42.3. Verifique as permissões e a criptografia

Utilize:

icacls "E:\Users\Carlos\Documents"

E, para arquivos suspeitos de EFS:

cipher /c "E:\Users\Carlos\Documents\Arquivo.docx"

42.4. Corrija somente o necessário

Se o problema for uma permissão NTFS insuficiente, ajuste a ACL de forma específica.

Se for criptografia, utilize as credenciais apropriadas.

Se houver falha física, priorize procedimentos de recuperação de armazenamento.

42.5. Valide os arquivos recuperados

Depois da recuperação, confirme que os documentos realmente abrem e possuem conteúdo íntegro.

A simples presença dos nomes dos arquivos não garante que os dados estejam completos.

43. Tabela definitiva VMIA: problema, causa e solução

Problema	Causa mais provável	Solução recomendada
Acesso negado após trocar de PC	ACL associada a conta antiga	Examinar SID e conceder permissão específica
Pasta solicita administrador	Propriedade ou ACL	Verificar proprietário e direitos
SID desconhecido nas permissões	Conta antiga não resolvida	Preservar ACL e avaliar acesso atual
Algumas pastas abrem, outras não	Herança ou ACE explícita	Comparar ACLs
Administrador não consegue acessar	Token, ACL ou proteção adicional	Verificar UAC e acesso efetivo
Arquivo EFS não abre	Chave privada indisponível	Recuperar certificado e chave legítimos
Unidade solicita chave	BitLocker	Desbloquear com chave correspondente
Junction apresenta acesso negado	Proteção de compatibilidade	Localizar diretório real
Arquivo não abre mesmo com permissão	EFS, corrupção ou aplicativo	Investigar causa específica
HD desconecta durante a leitura	Possível falha física	Preservar dados e diagnosticar hardware

44. Ferramentas recomendadas para diagnóstico

icacls e takeown

Ferramentas nativas para consultar e administrar permissões e propriedade NTFS. Exigem planejamento antes de qualquer alteração.

PowerShell

Permite consultar ACLs, proprietários, herança, grupos e informações do sistema.

Process Monitor

Ajuda a identificar operações recusadas, caminhos e processos envolvidos.Documentação oficial

cipher e certutil

Auxiliam na investigação de criptografia EFS e certificados.

manage-bde

Permite consultar informações de proteção BitLocker.

45. Como evitar problemas de acesso negado ao trocar de computador

A prevenção começa antes da remoção do HD ou SSD antigo.

45.1. Faça backup dos arquivos pessoais

Mantenha cópias atualizadas dos documentos importantes.

Sempre que possível, confirme que os arquivos podem ser restaurados.

45.2. Verifique a existência de EFS

Antes de reinstalar o Windows, identifique arquivos criptografados.

Se o EFS estiver em uso, preserve os certificados e as chaves privadas necessários.

45.3. Guarde a chave de recuperação BitLocker

Se a unidade estiver protegida pelo BitLocker, mantenha a chave de recuperação em local seguro e separado do dispositivo.

45.4. Planeje a migração de perfis

Copiar integralmente uma pasta de perfil não equivale a migrar corretamente uma conta do Windows.

Algumas configurações e dados de aplicativos dependem de identidades e mecanismos específicos.

45.5. Evite permissões excessivamente amplas

Não conceda controle total a todos os usuários como solução preventiva.

Isso pode comprometer a confidencialidade dos arquivos.

45.6. Preserve o computador antigo até validar a migração

Quando possível, não formate o dispositivo original imediatamente.

Primeiro confirme que os arquivos foram transferidos, abrem corretamente e não dependem de chaves ou configurações da instalação anterior.

46. FAQ — Perguntas frequentes sobre arquivos de outro HD com acesso negado

1. Por que meu HD antigo apresenta acesso negado no Windows 11?

Porque os arquivos podem manter permissões NTFS associadas a contas da instalação anterior. O Windows utiliza SIDs para identificar usuários, e uma conta criada no novo computador pode possuir um SID diferente, mesmo quando utiliza o mesmo nome.

2. Posso recuperar arquivos de outro computador sem formatar o HD?

Sim, em muitos casos. Se o disco estiver saudável e o problema envolver permissões NTFS, pode ser possível recuperar os dados por meio de uma correção autorizada e específica. Se houver criptografia, será necessário verificar as credenciais correspondentes.

3. O que significa o cadeado que aparece em alguns arquivos?

O cadeado pode representar diferentes condições, dependendo do aplicativo e da configuração do sistema. Ele não comprova, sozinho, que o arquivo esteja inacessível. É necessário verificar as permissões e testar o acesso.

4. O comando takeown resolve qualquer acesso negado?

Não. O takeown altera a propriedade quando utilizado com os privilégios necessários. Ele não concede automaticamente todos os direitos de acesso e não recupera chaves EFS ou BitLocker.

5. Qual é a diferença entre icacls e takeown?

O icacls permite consultar e administrar permissões NTFS. O takeown é utilizado para assumir a propriedade de arquivos ou diretórios. São ferramentas relacionadas, mas possuem finalidades diferentes.

6. Por que sou administrador e mesmo assim não consigo abrir a pasta?

Porque a associação ao grupo Administradores não elimina automaticamente todas as restrições. O resultado depende do token do processo, das ACLs, do UAC e de outros mecanismos de proteção.

7. O que significa aparecer um SID numérico nas permissões?

Significa que o Windows está apresentando um identificador de segurança. Isso pode ocorrer quando a conta correspondente não pode ser resolvida. O SID pode pertencer a uma instalação antiga ou a um ambiente de domínio indisponível.

8. Posso recuperar um arquivo criptografado com EFS depois de reinstalar o Windows?

A recuperação depende da disponibilidade do certificado e da chave privada apropriados ou de outro mecanismo legítimo de recuperação previamente configurado. Alterar permissões não substitui essas credenciais.

9. BitLocker e EFS são a mesma coisa?

Não. O BitLocker protege volumes, enquanto o EFS protege arquivos individualmente. Ambos utilizam criptografia, mas possuem mecanismos e procedimentos de recuperação diferentes.

10. É seguro conceder controle total para Todos?

Não é uma solução recomendada. Essa alteração pode ampliar desnecessariamente o acesso aos dados. Prefira conceder somente os direitos necessários à identidade autorizada.

11. Por que algumas pastas do HD antigo abrem e outras não?

Porque as permissões podem variar entre diretórios. Algumas pastas herdam regras de seus diretórios superiores, enquanto outras possuem entradas explícitas ou herança protegida.

12. Um HD com acesso negado pode estar defeituoso?

Sim, mas o acesso negado não comprova falha física. Erros de leitura, desconexões e lentidão extrema podem indicar problemas adicionais. É importante diferenciar falhas de segurança de problemas no armazenamento.

47. Conclusão: como recuperar arquivos bloqueados de outro HD no Windows 11

Arquivos copiados de outro HD podem apresentar cadeado, acesso negado ou solicitações de permissão administrativa por diferentes motivos.

As causas mais comuns envolvem permissões NTFS, identidades de segurança antigas, propriedade e herança.

Entretanto, alguns casos exigem investigação adicional.

Arquivos protegidos com EFS dependem de certificados e chaves privadas. Volumes BitLocker exigem desbloqueio com credenciais apropriadas. Junctions podem apresentar comportamentos específicos, enquanto discos com falha física exigem procedimentos de preservação.

Ferramentas como icacls, takeown, PowerShell e Process Monitor ajudam a identificar a origem do problema.

A solução mais segura é sempre aquela que corrige apenas a causa identificada, preservando os dados e evitando alterações desnecessárias nas permissões.

48. Precisa recuperar arquivos de um HD antigo? Conte com a VMIA

Se você conectou um HD ou SSD antigo ao computador e não consegue acessar seus documentos, fotografias, projetos ou pastas pessoais, a VMIA oferece suporte técnico especializado para diagnóstico e recuperação de acesso.

Os atendimentos podem incluir análise de permissões NTFS, investigação de SIDs antigos, diagnóstico de propriedade e herança, verificação de criptografia EFS e BitLocker e avaliação do estado do armazenamento.

A VMIA realiza atendimentos remotos, visitas técnicas agendadas e atendimento presencial mediante combinação prévia, com foco em computadores e notebooks Windows.

VMIA — Manutenção e Configuração

Atendimento em São Paulo, com agendamento e disponibilidade 24 horas.

WhatsApp: Fale com a VMIA

Telefone: (11) 99779-7772

E-mail: suporte@vmia.com.br

Site: vmia.site

Blog: vmia.com.br

Utilize referências técnicas oficiais da Microsoft:

• Microsoft Learn — icacls
• Microsoft Learn — takeown
• Microsoft Learn — cipher
• Microsoft Sysinternals — Process Monitor
• Microsoft Learn — manage-bde status