ID do usuário do Windows 10 visto no compartilhamento da Synology

1

Eu tenho um Synology DS1513 + executando o DSM5.0-4493 atualização 1 (um sistema operacional de vários anos).

Eu tenho o Windows 7 e 10 laptops montando esse disco, junto com um laptop Linux montado na mesma área via NFS.

Minha conta de desenvolvimento na caixa Linux e Synology é a ID do usuário 1000.

Gostaria que minhas caixas do Windows apresentassem esse ID de usuário, para que tivessem permissão total para editar tudo, criar e excluir arquivos, etc. (desenvolvo um software que deve funcionar em ambos os sistemas operacionais para poder editar e construir em ambos OS.)

Na caixa do Windows 7 há muito tempo, aparentemente também configurei seu ID de usuário para 1000 de alguma forma, mas na caixa do Windows 10 eu sou o ID do usuário 4294967294. Como posso alterar isso para 1000?

Quando eu "mapear a unidade de rede", tentei verificar "montar com credenciais diferentes", esperando que ele me perguntasse por um ID de usuário alternativo, mas parece que nunca consultou QUAIS as credenciais diferentes a serem usadas. (Eu também c Não acho que o disco aceitasse que eu deveria ser o usuário 1000.

Eu também tentei net use V: \diskstation\volume1\MyDisk MyPassword /USER:SynologyUserName e me disseram:

You can't connect to the file share because it's not secure. This
share requires the obsolete SMB1 protocol, which is unsafe and could
expose your system to attack. Your system requires SMB2 or higher. For
more info on resolving this issue, see:
https://go.microsoft.com/fwlink/?linkid=852747

Eu também tentei ir ao Painel de Controle \ Contas de Usuário \ Gerenciador de Credenciais \ Adicionar uma Credencial do Windows e digitar o compartilhamento \ diskstation \ volume1 \ MyDisk, MyUser e MyPassword. Após o OK:

This information cannot be 
saved.  Make sure all the information is correct and that all required fields are completed.

Error code: 0x80070057
Error Message: The parameter is incorrect.

Eu também tentei compartilhar como simplesmente diskstation. Após o OK, ele é aceito e aparece no Painel de Controle \ Contas de Usuário \ Gerenciador de Credenciais como "diskstation" em Credenciais do Windows. Mas então desmonto e remonto o compartilhamento, tento criar um arquivo, e o UID ainda é 4294967294, não o 1000 do nome da credencial que criei.

Eu também pesquisei "ID de usuário da sinologia do mapa". Não encontrando nada útil.

Eu fiz ssh e fiz find de / para quaisquer arquivos de configuração com samba no nome e não encontrei nada. (Bem, dois arquivos minúsculos, mas não parecem ser samba.conf ou qualquer coisa para mapear usuários.)

Eu também procurei sistematicamente através do painel de controle do synology sobre a interface http e nada.

    
por Swiss Frank 10.02.2018 / 07:02

1 resposta

0

Sua caixa Synology quase certamente está executando o Samba como a implementação dos "protocolos de compartilhamento de arquivos do Windows".

No Samba, há um conceito chamado mapeamento UID, que mapeia os SIDs estilo Windows (longas seqüências de números que são gerados automaticamente quando você faz um novo usuário no Windows) para UIDs estilo UNIX (que geralmente começam com números pequenos como 1000 e aumentar em 6 dígitos para determinados sistemas).

Isso ocorre porque os SIDs do Windows, que são os identificadores numéricos das contas do Windows, são fundamentalmente diferentes dos UIDs do UNIX, que são os identificadores numéricos das contas do UNIX. Eles têm formatos diferentes e a mudança de um SID do Windows não é fácil (embora seja muito fácil alterar um UID do UNIX com permissões de root).

Veja um exemplo do formato de um SID do Windows: S-1-5-21-1180699209-877415012-3182924384-500

A razão pela qual temos que "mapear" entre SIDs e UIDs é, mesmo que você tente alterar um SID do Windows para algo como 1000 , não funcionaria, porque o Windows espera SIDs para os usuários terem uma certa extensão e sintaxe, incluindo começando com um "S" e tendo um monte de números longos com traços neles.

Se for suficientemente antigo, provavelmente ele está executando o Samba 3. O mapeamento de UID no Samba3 é discutido aqui .

O mapeamento UID no Samba4 é conceitualmente o mesmo, mas implementado por sua opção de "backend de mapeamento de identidade" - veja aqui .

Veja como fazer o mapeamento de identidade em um controlador de domínio Samba4: aqui .

No entanto, os artigos wiki estão de lado (eles fornecem informações conceituais muito úteis para que você entenda o que está acontecendo nos bastidores), a informação mais útil que pude encontrar especificamente sobre essa combinação de coisas:

  • compartilhamentos de arquivos do Windows
  • Synology
  • Mapeamento de clientes para usuários na caixa Synology

... está em esta resposta no AskUbuntu , que lida com o usuário < em> nomes , não IDs do usuário .

Sevocêachouessainformaçãoútil,vocêdeveclicarnolinkparaAskUbuntuacima,elançarAaronumupvoteporsuaboaresposta.

OprincipalinsightparatirararespostadeAaronéque,seoseunomedeusuárioesenhadoWindowscorresponderemexatamenteaonomedeusuárioesenhadousuáriodoSynologyServer,vocêpoderáentrarsemfazernenhumaautenticaçãomanualtemquedigitarqualquernomedeusuário/senha),edoladodoSynology,oUIDquevocêteráparapermissõesdearquivo/diretórioserádefinidocombasenoUIDdousuárionoladoSynologyquetemomesmousuárionomecomosuacontadoWindows.

OutrarazãoqueprovavelmentenãofuncionanoWindows10:SevocêfizerloginnoWindows10comsuacontadaMicrosoft,seunomedeusuárionãoéexatamenteoquevocêachaqueé!Seunomedeusuárioéoendereçodee-maildasuacontadaMicrosoft,sobocapô;apenasapareceparaserqualquernomedeusuário"amigável" que você forneceu no terreno do Win32 (como se você tivesse a pasta, C:\Users\swissfrank em vez de C:\Users\[email protected] ).

Portanto, ao acessar o servidor Synology com um nome de usuário de [email protected] (em vez do usuário swissfrank que foi criado corretamente no lado Synology como ID de usuário UNIX 1000), ele o considera um usuário diferente. Isso é por design e definitivamente significa que você precisaria de um mapa de nome de usuário como na resposta de Aaron. O conteúdo seria algo como:

swissfrank = [email protected]

    
por 10.02.2018 / 07:14