Erro do sistema WebDav 67 no Windows XP

Problema: estou tendo problemas para que o WebDav funcione na linha de comando do Windows XP, tanto no Service Pack 2 quanto no Service Pack 3.

C:\>net use z: https://mywebsite.com/software/
System error 67 has occurred.

The network name cannot be found.

Eu testei isso com dois servidores webdav. O Ubuntu Apache e o Windows Server 2003 IIS. Ambos obtêm o mesmo resultado.

Coisas que não funcionaram:

1. Instalei o seguinte Microsoft KB nas minhas máquinas XP sem sucesso.

2. Eu também encontrei a seguinte chave de registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters UseBasicAuth REG_DWORD 1

3. Eu tento o seguinte ao tentar usar algumas soluções que descobri na Web, todas produzindo o mesmo resultado.

   net use z: https://mywebsite.com/software
   net use z: https://mywebsite.com/software#
   net use z: https://mywebsite.com/software/
   net use z: https://mywebsite.com/software/#
   

4. Eu também tentei todas as combinações acima adicionando um usuário a ele /user:usere /user:user@domain.

5. Eu também tentei usar http://ao invés de https://.

6. eu tentei "\\server.com@ssl:443\folder"

7. Analisei questões relacionadas à rede, como @WesleyDavid havia apontado.

Coisas que funcionam:

• I pode se conectar à pasta WebDAV através da URL e com mapeamento no local de rede, com o XP. Mas a linha de comando não funciona (preciso de uma letra de unidade).
• O Windows 7 funciona perfeitamente com o mesmo comando.

Meu Delemma:

Eu preciso disso para trabalhar com uma letra de unidade. O que mais posso tentar fazer com que isso funcione?

Usando o WedDAV ativado no OS X Lion Server, a sintaxe no XP é:

NET USE * http: // URL do servidor / webdav / nome de usuário senha / usuário: nome de usuário

Isso funciona, mas não é possível descobrir como escolher entre vários compartilhamentos para o mesmo usuário (sempre o padrão é o diretório da conta do usuário) ...

Eu tive os mesmos problemas para uma conexão HTTP WebDav (ainda não tentei com HTTPS, mas também deveria funcionar). Por favor, tente o seguinte, funcionou para mim:

Para habilitar a autenticação básica no computador cliente, siga estas etapas:

1. Clique em Iniciar e, em seguida, clique em Executar.
2. Na caixa Abrir, digite regedit e clique em OK.
3. Localize e clique na seguinte subchave do Registro: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ WebClient \ Parameters
4. No menu Editar, aponte para novo e, em seguida, clique em valor DWORD.
5. Digite UseBasicAuth e, em seguida, pressione Enter.
6. No menu Editar, clique em Modificar.
7. Na caixa Dados do valor, digite 1 e clique em OK. Nota A autenticação básica será ativada se a entrada do registro UseBasicAuth estiver definida como um valor diferente de zero. A autenticação básica será desativada se a entrada do registro UseBasicAuth não estiver presente ou se a entrada do registro UseBasicAuth estiver definida como 0 (zero).
8. Saia do Editor do Registro e reinicie o computador.

Observe que a chave é chamada BasicAuthLevel no Vista e mais recente

Então conecte

net use X: "http://mywebsite.com/software" /User:username password

Fonte http://support.microsoft.com/kb/841215/en-us

Zero Guess: Acabei de editar isso aqui. Livre-se da barra à direita net use z: https://mywebsite.com/software/para que ela leianet use z: https://mywebsite.com/software

Primeiro palpite:

Eu não gosto da aparência de /user:user@domain. Eu já vi coisas incompletas com isso em algumas ferramentas da CLI do Windows (mesmo que sim, deva funcionar bem). Você tentou o formato /u:domain\user?

Palpitar:

1. Entre no gerenciamento de hardware e selecione Visualizar >> " Mostrar dispositivos ocultos "
2. Abra o nó "Não Plug and Play Drivers"
3. Desativar tradutor de endereços de rede IP

Sabe-se que isso causa o erro 67, que é o coração do problema. Um erro de comunicação.

Terceira palpite

Corrupção Winsock! Acontece. Olhe para dentro netsh winsock resetenetsh winsock reset catalog

Você pode ler mais neste artigo da base de dados de conhecimento .

Quarta palpite:

Às vezes, o erro 67 pode ser causado por um problema de nível de hardware no lado do cliente e do servidor, geralmente envolvendo os drivers. Duas possibilidades:

1. Redefina a pilha TCP / IP no cliente usando netsh int ip reset. Eu sei, eu sei - é a administração do culto de carga. Apenas tente. =)
2. Atualize para os drivers de rede mais recentes para obter o número exato do modelo da placa em todas as máquinas envolvidas. Até os servidores. Em minha opinião, em algum lugar, me lembro do erro 67 sendo lançado nos clientes e da placa de rede do servidor sendo atualizada para resolver o problema.

Quinta palpite

Estamos chegando a pickins finos aqui em baixo. Tente isso no modo de segurança com rede. As conexões WebDAV devem poder ser feitas. Gostaria de saber se algum driver de rede estranho interferente está interferindo, embora isso devesse ter sido resolvido com a atualização dos drivers no Guess # 1.

Você não pode mapear uma unidade de rede para uma conexão https anterior ao Windows Vista, pelo menos não com o comando Net. Isso tem a ver com um problema com o mini redirecionador WebDav. Verifique o seguinte: http://www.autohotkey.com/forum/topic44471.html

Tente por favor

C:\>net use z: http://user:password@mywebsite.com/software

A outra coisa que eu vejo é:

net use * z: https://mywebsite.com/software password /user:username

Você consultou este artigo da Microsoft KB? Pode valer a pena tentar.

Você pode receber uma mensagem de erro "O nome da rede não pode ser encontrado" ao usar o nome de domínio totalmente qualificado para conectar-se a um computador remoto a partir de um computador com Windows Server 2003, Windows XP ou Windows 2000

Eu também recomendaria o uso do Fiddler para bisbilhotar o tráfego ao emitir o net usecomando. Você pode ver algo um pouco mais interessante que o Erro do sistema WebDav 67.

Mmm. E se:

net use z: https://mywebsite.com:443/software/

Além disso, quando você tenta fazer 'net use z: http://mywebsite.com/software/ ' (o ponto 5 do que não funcionou) a porta 80 está ativa no servidor de destino? Claramente, esse é um problema do XP - podemos isolá-lo para XP e HTTPS ou XP e Webdav? Seus logs de eventos mostram alguma coisa?

Além disso: o comando net use pode estar usando as configurações de segurança da Internet do Windows para mapear a unidade? Pode ser necessário colocar https://mywebsite.com nos sites confiáveis . Procure no IE -> ferramentas -> segurança ou no seu painel de controle.

Webdav no IIS: net use * http: // WEBSITE / DavWWWRoot PASSWORD / usuário: USER @ DOMAIN

se você usa o IIS, a pasta Raiz tem esse nome DavWWWRoot, algum cliente é resolvido automaticamente (windows 10 e windows 7), mas em outro caso você deve especificar (windows xp). Este trabalho me forma