Autorisation de Robocopy refusée

Robocopy est préinstallé avec Windows 7. Je l'ai utilisé plusieurs fois dans le passé. J'ai essayé de copier un dossier sur un partage distant avec

robocopy c:\source "\\server\share\path" /s /r:2 /w:2` 

En conséquence, ma permission est refusée. En utilisant l'explorateur, je peux copier des fichiers sur ce partage. J'ai ouvert une invite de commande avec des autorisations d'administrateur avec le même résultat. Le partage est en lecture / écriture pour le public.

EDIT J'ai réussi à mapper un driveletter sur le partage, mais robocopy échoue toujours

EDIT J'ai ajouté le commutateur / B sans succès. L'erreur exacte est:

2009/09/26 20:43:14 ERROR 5 (0x00000005) 
    Accessing Destination Directory \\drobo\Drobo\fotos\__NEW\Ericsson\

Cité d' ici :

Dans mon cas, j'ai commencé avec un contrôle total sur les partages source et destination. Le problème était que Robocopy réinitialisait l'ACL sur le partage de destination à une valeur nulle (personne n'a l'autorisation) avant de commencer à récurser les sous-répertoires. Après quelques tests rapides, ma conclusion est que Robocopy ne gère pas les autorisations héritées. Supposons que vous copiez C: \ Share1 vers D: \ et que C: \ Share1 hérite ses autorisations du répertoire racine C: \, il n'a en fait pas de liste de contrôle d'accès explicite. Par conséquent, lorsque vous copiez son ACL, vous copiez en fait ... rien. En copiant une ACL vide vers votre destination, vos autorisations sont supprimées à la première étape de la copie et toutes les écritures suivantes sur le partage échouent avec l'erreur 5.

Il s'agit uniquement d'un problème lorsque vous copiez à partir d'une source à laquelle vous accédez AVEC des autorisations héritées et d'une destination à laquelle vous accédez SANS autorisations héritées. Si vous copiez C: \ (qui vous a explicitement dans son ACL), vers D: \, il n'y a pas de problème. Si tel est bien votre problème, vous pouvez le résoudre en vous ajoutant explicitement à l'ACL source avec un contrôle total. Lorsque la copie s'exécute, votre entrée ACL est dupliquée vers la destination et les copies de fichier suivantes peuvent être écrites. Vous pouvez annuler vos modifications (à la fois sur la source et sur la destination) une fois la copie terminée.

Si vous continuez d'avoir des problèmes malgré ce qui précède, vous voudrez peut-être envisager d'essayer le commutateur / B, qui tente de sauvegarder le fichier en utilisant vos privilèges en tant qu'opérateur de sauvegarde. Cela vous permettra de copier des fichiers que vous n'auriez pas pu autrement, par exemple, si vous n'êtes pas sur l'ACL sur votre partage de destination. Par défaut, Robocopy tente de copier une copie redémarrable. En abandonnant les copies redémarrables, le pire des cas est que vous perdiez le fichier en cours de transfert en cas de perturbation. La prochaine passe redémarrera ce fichier depuis son début au lieu de le faire à mi-chemin.

J'espère que ça t'as aidé. Voici une citation du document Robocopy de Microsoft concernant le commutateur / B:

Citation:

Si vous copiez des informations de sécurité NTFS (ACL) avec des données de fichier, il est possible de copier des fichiers auxquels vous avez un accès en lecture, mais pas en écriture. Une fois qu'un tel fichier est copié une fois et que les ACL sont appliquées, vous pouvez constater que pour obtenir une erreur «Accès refusé» lorsque vous essayez de recopier le fichier. Dans cette situation, vous devez utiliser le commutateur / B ou / ZB pour copier les fichiers en mode de sauvegarde.

/ B copie tous les fichiers avec une sémantique de sauvegarde (mode de sauvegarde). / ZB tente d'abord de copier des fichiers en mode redémarrable (pour une meilleure résilience) mais si cela échoue avec une erreur «Accès refusé», il réessaye automatiquement la copie en utilisant le mode de sauvegarde.

Essayez de copier des fichiers en utilisant l' Backupindicateur:

/ B: copier des fichiers en mode sauvegarde.

En plus des réponses précédentes, je peux étendre le correctif qui a fonctionné pour moi. Dans mon cas, j'avais des dossiers et des fichiers locaux dont la propriété avait été revendiquée par un autre utilisateur du système. J'ai simplement revendiqué la propriété de tous les dossiers et sous-dossiers et tout a bien fonctionné sans le commutateur de sauvegarde.

Revendiquez la propriété d'un dossier et de ses sous-dossiers: http://technet.microsoft.com/en-us/magazine/ff404240.aspx

Vous pouvez également écrire un script pour résoudre ce problème automatiquement

# To run robocopy with logging which logs errors
robocopy source dest /MIR /NP /TEE /R:0 /W:1 /FFT /LOG+:log.txt 

# get errors from log and use set-content so it only writes if there are errors.
get-content log.txt | select-string "0x00000005" | set-content errors.log

#if statements to check if it even had errors.  only if errors go into if statement.
if (test-path errors.log) {

    #now capture the paths exactly.  Get-unique so it writes one error only once. 
    #Will assume you're using UNCs to copy vs. drive letters, please modify as necessary
    select-string -path errors.log -pattern "\\\\.*$" | %{ $_.Matches[0].captures[0].value} | get-unique > paths.log

    #just do foreach loop for each path.
    foreach ($path in $paths) { 

        #use subinacl to take ownership and assign permissions, it is better and faster 
        #than icacls and ps ways but you can use whatever works.  Report the changes you 
        #made.  if '$path' is a folder then you will need to modify subinacl command to 
        #inherit etc.  look it up.
        .\subinacl /file "$path" /setowner="YOUR ID" >> change-perms.log
        .\subinacl "$path" /grant="your ID"=F >> change-perms.log

    }

    #run your robocopy command again to copy missed file in previous step. 
    robocopy source dest /MIR /NP /TEE /R:0 /W:1 /FFT /LOG+:log.txt 

    #Delete the error log file so it does not go in to if loop next time you run.
    remove-item error.log (use force, erroraction etc as necessary)

}