☰

Erros de acesso negado em alguns arquivos na pasta compartilhada

tag-icon • tag-icon windows windows-xp permissions
Erros de acesso negado em alguns arquivos na pasta compartilhada

Eu tenho um sistema XP Pro usando o Simple File Sharing. O compartilhamento está habilitado para uma pasta específica, bem como "Permitir que usuários da rede alterem meus arquivos".

Ao copiar (ler) os arquivos compartilhados de outra máquina, alguns deles (cerca de 20 em 1000, apresentam um erro de Acesso Negado. Nenhum programa está com os arquivos abertos.

Tenho que ir até a máquina que está compartilhando os arquivos e rodar

CACLS C:\MySharedFolder\*.* /T /e /g Everyone:c

Isso corrige o problema e todos os arquivos podem ser acessados. Mas é inconveniente ter que executar esse comando. Depois de alguns dias ou semanas, o erro retorna.

Qual é a causa raiz desse erro? Parece que o programa que acessa os arquivos (neste caso o Eudora) está configurando as permissões incorretamente - mas por que apenas nesta máquina? Tenho outras máquinas com configurações idênticas de pastas compartilhadas que nunca apresentam esse problema.

Responder1

Classicamente, isso pode ser causado por usuárioscortando e colandoarquivos em um compartilhamento. Isso significa que se os arquivos (na origem) foram configurados para não herdar permissões da pasta pai, quando forem recortados e colados no destino, eles manterão suas permissões antigas.

Responder2

Esta não é realmente uma resposta, mas mais informações (não é possível usar comentários devido ao limite de caracteres). Ainda estou tentando entender e resolver esse problema.

Esta é a aparência das permissões de um arquivo "ruim" no CACLS (as permissões impedem a cópia de outra máquina):

C:\...\Mail\descmap.pce BUILTIN\Administrators:F
                        NT AUTHORITY\SYSTEM:F
                        MARS\Tim:F
                        BUILTIN\Users:R

Esta é a aparência de um arquivo "bom":

C:\...\Mail\In.mbx Everyone:C
                   BUILTIN\Administrators:F
                   NT AUTHORITY\SYSTEM:F
                   MARS\Tim:F
                   BUILTIN\Users:R

Esta é a aparência das permissões da pasta "Mail" (pai):

C:...>cacls mail
C:...\Mail Everyone:(OI)(CI)C
           BUILTIN\Administrators:F
           BUILTIN\Administrators:(OI)(CI)(IO)F
           NT AUTHORITY\SYSTEM:F
           NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
           MARS\Guest:F
           CREATOR OWNER:(OI)(CI)(IO)F
           BUILTIN\Users:R
           BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                     GENERIC_READ
                                     GENERIC_EXECUTE

           BUILTIN\Users:(CI)(special access:)
                             FILE_APPEND_DATA

           BUILTIN\Users:(CI)(special access:)
                             FILE_WRITE_DATA

Os atributos "Everyone:C" e "BUILTIN\Administrators:F" de alguma forma são removidos dos arquivos problemáticos. Arquivos diferentes são afetados em momentos diferentes. Não parece haver nenhuma consistência.

Responder3

Esta não é uma solução, mas algo para comparar notas ...

Eu tenho quase exatamente o mesmo problema. No entanto, no meu caso, eu tinha um ID de usuário fazendo login em um servidor Samba-3 atuando como PDC (portanto, tenho máquinas associadas ao domínio).

Este ID de usuário poderia acessar um arquivo da caixa WinXP, mas na máquina Win7-PRO eles obteriam erro de acesso negado. O arquivo não estava sendo movido de um compartilhamento para outro ou de uma pasta para outra. Era apenas uma pasta pública que todos na empresa também tinham acesso.

Tentei de tudo para resolver e a única coisa que encontrei foi reinstalar a estação de trabalho com uma cópia limpa do Windows-7 corrigindo o problema.

No meu caso, a interação do Windows7 com o SAMBA parecia ser o problema. Interessante é que tenho outras caixas Win7 nas quais o problema não aconteceu com outros usuários, mas esse ID de usuário específico só teve o problema em caixas Win7.

Até excluí o ID do usuário e o recriei, e limpar o perfil móvel não resolveu o problema. Também descobri que se eu dissesse ao usuário para usar um ID de usuário recém-criado que não correspondesse ao ID de usuário antigo, o problema ainda existiria.

Foi se esta estação de trabalho Windows-7 fizesse com que o problema aparecesse com o ID do usuário que depois viajou com esse ID de usuário para outras estações de trabalho Win-7.

A reorganização da estação de trabalho Win-7 faz com que o problema desapareça.

informação relacionada