Eu sugeriria mudar para o robocopy, pois xcopy /? diz "NOTA: o Xcopy agora está obsoleto, por favor use o Robocopy."
Eu tenho um sistema Windows 7 Ultimate que mapeia um compartilhamento do Samba 3.0.33. Eu não tenho problemas para ler, escrever ou substituir quaisquer arquivos ou diretórios do Windows File Explorer. Eu tentei configurar um script de sincronização push / pull no cliente windows usando xcopy. Eu estou tentando substituir quaisquer arquivos mais recentes que o arquivo / diretório correspondente em qualquer direção. A cópia do servidor para o cliente funciona muito bem. A cópia do cliente para o servidor falha com "acesso negado" (quando o diretório já existe - novos diretórios podem ser criados sem problemas).
Este é o meu script do Windows:
xcopy c:\source_dir z:\dest_dir /D /E /I /F /R /Y
xcopy z:\dest_dir c:\source_dir /D /E /I /F /R /Y
Aqui está o que eu vejo para o primeiro comando:
C:\Source_dir>xcopy c:\Source_dir\test z:\Dest_dir\test /E /I /F /R /Y
Access denied
Unable to create directory - Z:\Dest_dir\test
0 File(s) copied
O mesmo comando funciona bem em um sistema XP conectado ao mesmo servidor. Deve haver algo que estou perdendo - alguma idéia do que possa ser?
Obrigado!
PS: Esqueci de mencionar que, se o diretório ainda não existe no servidor, o comando xcopy para o servidor é bem-sucedido.
PPS: Robocopy produz resultados idênticos.
Eu sugeriria mudar para o robocopy, pois xcopy /? diz "NOTA: o Xcopy agora está obsoleto, por favor use o Robocopy."
Percebeu que foi feito backup de novos diretórios e que o proprietário e o grupo listados eram diferentes dos diretórios e arquivos mais antigos. Resolvi meu XP para o problema de permissão de compartilhamento do Samba alterando o proprietário e o grupo. Backup xcopy funcionando bem agora!
xcopy d:\mypict~1\* \linuxserver\backups\homestud\mypictures /mschiy
estava dando
Access denied
Unable to create directory - \linuxserver\backups\homestud\mypictures02
mesmo sem arquivos necessários. Quando eu chmod esse diretório de 2002 para ninguém e nogroup - seria passar esse erro dir! Então eu reapliquei recursivamente todos os arquivos e pastas.
Certifique-se de que a conta à qual você se conecta tenha permissão no lado do servidor para criar diretórios Z: \ Dest_dir \
O mkdir z: \ Dest_dir \ test cria o mesmo resultado?
Como dito acima, eu verificaria as permissões no lado do servidor.
Desculpe ressuscitar uma pergunta dos mortos, mas eu acho que você precisa dar uma olhada na sua máscara de criação nas configurações do seu samba. O padrão é 755, portanto, se a sua conta de usuário não for o proprietário do diretório, os novos diretórios ou arquivos criados por você não serão graváveis por essa conta. O diretório raiz provavelmente possui permissões de arquivo unis mais permissivas, talvez 775, e é por isso que você é capaz de criar novos arquivos e diretórios em primeiro lugar.
Eu também me deparei com esse problema (Win 7 e 8) com robocopy e xcopy falhando com mensagens de erro indicando falha ao criar pastas, enquanto a cópia via explorer ou copy ainda funcionava.
Consegui fazer isso funcionar usando as seguintes opções de configuração:
force create mode e force directory mode
Especificamente 0774 e 0775 na minha configuração. Aparentemente, algo está ficando descontrolado com permissões quando robocopy ou xcopy estavam sendo usados. Isso parece indicar algum tipo de problema de configuração, e essa solução é bastante indiscriminada, mas é tudo o que consigo descobrir agora.
O servidor é FreeNAS 9.2.1.3 executando o Samba 4.1.6