As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Migrar um Linux WorkSpace para um sistema operacional diferente
Você pode migrar um Linux existente WorkSpace para um pacote de sistema operacional Linux diferente, preservando o diretório inicial, os arquivos e os dados do usuário. A migração substitui o volume raiz (sistema operacional) por um novo pacote, mantendo o volume do usuário (`/home`) intacto. Isso é diferente de uma reconstrução, que atualiza o volume raiz com o mesmo pacote de sistema operacional.
O WorkSpace recurso Migrate gerencia todo o processo automaticamente, incluindo a correção da propriedade do arquivo e a limpeza do ambiente de desktop quando necessário.
**Topics**
+ [Caminhos de migração compatíveis](#linux-migration-paths)
+ [Pré-requisitos](#linux-migration-prerequisites)
+ [Como migrar um WorkSpace](#linux-migration-how-to)
+ [Post-migration verificação](#linux-migration-verification)
+ [O que acontece durante a migração](#linux-migration-during)
+ [Migração do Amazon Linux 2](#linux-migration-from-al2)
+ [Migração entre distribuições modernas](#linux-migration-modern-distros)
+ [O que os usuários mantêm e quais mudanças](#linux-migration-preserved)
+ [Auto-stop e sempre ativo WorkSpaces](#linux-migration-autostop-alwayson)
+ [Limitações conhecidas](#linux-migration-limitations)
+ [Solução de problemas](#linux-migration-troubleshooting)
## Caminhos de migração compatíveis
A tabela a seguir mostra os sistemas operacionais de origem e destino suportados para a WorkSpace migração do Linux.
| SO de origem | Ubuntu 22.04 | Gráficos do Ubuntu 22.04 | Ubuntu 24.04 | RHEL 8 | RHEL 9 | Rocky 8 | Rocky 9 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Amazon Linux 2 (PCoIP) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Amazon Linux 2 (WSP) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ubuntu 22.04 | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Gráficos do Ubuntu 22.04 | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ubuntu 24.04 | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ |
| RHEL 8 | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| RHEL 9 | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ |
| Rocky 8 | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ |
| Rocky 9 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
**O Amazon Linux 2** é uma fonte de migração válida, mas não é um destino de migração válido. O Amazon Linux 2 chegou ao fim da vida útil e novos WorkSpaces não podem ser criados com pacotes AL2.
Todos os caminhos de migração entre Ubuntu, RHEL e Rocky Linux são suportados em ambas as direções. Você pode atualizar (por exemplo, RHEL 8 → RHEL 9) ou fazer o downgrade (por exemplo, Ubuntu 24.04 → Ubuntu 22.04). Você também pode migrar entre famílias de distribuição (por exemplo, Rocky 9 → Ubuntu 24.04 ou RHEL 9 → Rocky 8). A única restrição é que você não pode migrar um WorkSpace para o mesmo pacote que ele já está usando.
As migrações do Amazon Linux 2 exigem correção automática de propriedade do ID de usuário e limpeza do ambiente de desktop. As migrações entre todas as outras distribuições (Ubuntu, RHEL, Rocky) não exigem correção de propriedade porque todas essas distribuições usam SSSD para integração com o Active Directory, que atribui IDs de usuário estáveis.
## Pré-requisitos
Antes de migrar um Linux WorkSpace, verifique o seguinte:
+ **WorkSpace estado** — WorkSpace Deve estar no `AVAILABLE` estado. Você não pode migrar um WorkSpace que esteja iniciando, parando ou em estado de erro.
+ **Sem confiança na floresta WorkSpace do Active** Directory — O diretório não deve ter relacionamentos de confiança na floresta configurados. O SSSD, usado por todas as distribuições Linux modernas para integração com o Active Directory, não oferece suporte ao Forest Trust. Se o Forest Trust estiver configurado, a migração falhará durante o provisionamento.
+ **Armazenamento suficiente do EBS** — WorkSpace É necessário ter armazenamento suficiente do EBS para a operação de migração.
## Como migrar um WorkSpace
### Usar o AWS Console de Gerenciamento
1. Abra o WorkSpaces console da Amazon em [https://console.aws.amazon.com/workspaces/](https://console.aws.amazon.com/workspaces/).
1. No painel de navegação, escolha **WorkSpaces**.
1. Selecione o WorkSpace que você deseja migrar.
1. Escolha **Ações** e, em seguida, escolha **Migrar. WorkSpace**
1. Selecione o pacote do sistema operacional de destino.
1. Escolha **Migrate (Migrar)**.
### Usar o AWS CLI
Use o `migrate-workspace` comando para migrar um WorkSpace para um pacote diferente:
```
aws workspaces migrate-workspace \
--source-workspace-id ws-1234567890abcdef0 \
--bundle-id wsb-jttwgmx20 \
--region us-east-1
```
Para encontrar os IDs de pacotes de destino disponíveis:
```
aws workspaces describe-workspace-bundles \
--query 'Bundles[?contains(Name, `Ubuntu`) || contains(Name, `Rocky`) || contains(Name, `RHEL`)].{Name:Name,BundleId:BundleId}' \
--output table
```
### Monitorando o status da migração
A migração normalmente leva de 20 a 30 minutos. Monitore o WorkSpace status:
```
aws workspaces describe-workspaces \
--workspace-ids ws-1234567890abcdef0 \
--query 'Workspaces[0].State' \
--output text
```
As WorkSpace transições pelos seguintes estados: `AVAILABLE` → `PENDING` → `AVAILABLE` (em caso de sucesso) ou `ERROR` (em caso de falha). Se a migração falhar durante o provisionamento, o plano de controle restaurará automaticamente o original. WorkSpace
## Post-migration verificação
Depois que a migração for concluída, verifique o seguinte:
**Verifique o WorkSpace status**
Confirme WorkSpace se está no `AVAILABLE` estado no AWS console ou por meio da CLI.
**Verifique o login do usuário**
Faça com que o usuário faça login no WorkSpace e confirme se a área de trabalho está carregando corretamente.
**Verifique o registro de migração**
Para migrações de AL2, revise o registro de migração para obter detalhes sobre o que foi alterado:
```
cat ~/workspace-migration-log-*/user-id-migration.txt
```
Esse registro mostra os IDs de usuário antigos e novos, o número de arquivos alterados em cada fase e os registros de data e hora.
**Verifique o status da Fase 2**
Para verificar se a migração em segundo plano foi concluída:
```
# Check if the Phase 2 service is still running
systemctl is-active ws-migrate-phase2.service 2>/dev/null
# "inactive" or "not found" means Phase 2 has completed
# "activating" means Phase 2 is still running (Type=simple service)
```
## O que acontece durante a migração
Quando você inicia uma migração, as seguintes etapas ocorrem:
1. O volume do usuário (`/home`) é separado do existente WorkSpace.
1. O existente WorkSpace é descartado.
1. Um novo WorkSpace é criado a partir do pacote do sistema operacional de destino.
1. O volume do usuário é reconectado ao novo WorkSpace em`/home`.
1. O novo WorkSpace é provisionado: a rede é configurada, a instância se junta ao Active Directory e o diretório inicial do usuário está configurado.
1. Ao migrar do Amazon Linux 2, a propriedade do arquivo é corrigida e a configuração antiga do desktop é limpa (consulte[Migração do Amazon Linux 2](#linux-migration-from-al2)).
1. Ele é WorkSpace reinicializado e fica disponível para o usuário fazer login.
O diretório inicial do usuário é armazenado em um volume EBS separado que é preservado durante a migração. Todos os arquivos `/home/{{username}}` sobrevivem à transição, incluindo documentos, chaves SSH, configuração do shell e dados do aplicativo.
## Migração do Amazon Linux 2
As migrações do Amazon Linux 2 envolvem etapas adicionais que são processadas automaticamente. Esta seção explica o que acontece e por quê.
### Por que as migrações de AL2 são diferentes
**O Amazon Linux 2 usa o **Winbind** para integração com o Active Directory, enquanto todas as distribuições Linux mais recentes (Ubuntu, RHEL, Rocky) usam SSSD.** Esses dois sistemas atribuem IDs de usuário POSIX diferentes ao mesmo usuário do Active Directory:
+ **Winbind** (AL2): atribui IDs de usuário usando um esquema algorítmico imprevisível (por exemplo, UID 1000).
+ **SSSD** (distribuições modernas): atribui IDs de usuário estáveis derivadas do SID do Active Directory (por exemplo, UID 1285401133).
Após a migração, todos os arquivos no diretório inicial do usuário pertencem ao antigo UID do Winbind. O usuário não pode acessar seus próprios arquivos até que a propriedade seja corrigida para corresponder ao novo UID SSSD.
**Além disso, o Amazon Linux 2 usa o ambiente de desktop **MATE** (GNOME 2), enquanto as distribuições mais recentes usam o GNOME 3.x.** Os arquivos de configuração do MATE estão em conflito com o GNOME 3.x e devem ser limpos para garantir que a área de trabalho funcione.
### Two-phase correção de propriedade
Para evitar tempos limite de provisionamento, a correção de propriedade é dividida em duas fases.
**Fase 1 (durante o provisionamento)**
Corrige a propriedade de arquivos essenciais para desktop necessários para login imediato:
+ Diretório inicial em si
+ Chaves SSH () `~/.ssh/`
+ Configuração de desktop (`~/.config/`)
+ Perfis Shell (`.bashrc`,`.bash_profile`,`.profile`)
+ Qualquer arquivo ou diretório de nível superior sem permissão de leitura mundial
A fase 1 é concluída rapidamente, independentemente do tamanho total do diretório inicial, garantindo que o provisionamento nunca falhe devido aos grandes diretórios iniciais.
**Fase 2 (em segundo plano, após a reinicialização)**
Corrige a propriedade de todos os arquivos restantes:
+ É executado como um serviço systemd (`ws-migrate-phase2.service`) na inicialização
+ Tenta novamente a resolução do usuário por até 10 minutos se o SSSD ainda não estiver pronto na inicialização — se a resolução atingir o tempo limite, o serviço permanecerá ativado e tentará novamente na próxima inicialização
+ Usa I/O prioridade de inatividade e menor prioridade de CPU — não afeta a experiência do usuário
+ O usuário pode fazer login e trabalhar normalmente enquanto a Fase 2 é executada
+ As correções de propriedade para diretórios grandes (mais de 10 milhões de arquivos) continuarão sendo concluídas em segundo plano
+ Self-removes o arquivo de serviço systemd após a conclusão bem-sucedida
### Limpeza do ambiente de desktop
Durante a migração do AL2, os seguintes arquivos de configuração do desktop MATE são movidos para um diretório de backup dentro do log de migração (`~/workspace-migration-log-YYYYMMDD/removed-configuration/`):
+ `~/.config/dconf/user`— banco de MATE-specific dados dconf
+ `~/.gconf/`— Diretório GConf legado
+ `~/.config/mate-session/`— Configuração da sessão MATE
+ `~/.config/mate-panel/`— Configuração do painel MATE
+ `~/.local/share/mate-panel/`— Dados do aplicativo do painel MATE
+ `~/.config/pluma/`— Configurações do editor de texto MATE
+ `~/.config/caja/`— Configuração do gerenciador de arquivos MATE
+ `~/.config/marco/`— Configurações do gerenciador de janelas MATE
+ `~/.config/gtk-2.0/`, `~/.config/gtk-3.0/` — configurações do tema GTK
+ `~/.local/share/recently-used.xbel`— Lista de arquivos recentes
Esses arquivos não são excluídos — eles são movidos para o diretório de backup e podem ser recuperados, se necessário. Após a limpeza, a área de trabalho carrega com a aparência padrão do GNOME 3.x.
### Restauração do contexto SELinux
Quando o destino da migração é RHEL ou Rocky Linux, os contextos de segurança do SELinux são sempre restaurados em todo o diretório inicial do usuário (`/home/{{username}}`), independentemente do sistema operacional de origem. Isso se aplica a todos os caminhos de migração que têm como alvo uma SELinux-enabled distribuição, incluindo:
+ Migrações de fontes não SELinux (Ubuntu, AL2), nas quais os arquivos não têm rótulos SELinux por completo.
+ Migrações entre SELinux-enabled distribuições (por exemplo, RHEL 8 → RHEL 9, Rocky 8 → Rocky 9 ou RHEL 9 → Rocky 9). As versões da política do SELinux e as definições de contexto de arquivo podem mudar entre as versões principais.
Em todos os casos, a restauração do contexto garante que os arquivos tenham os rótulos de segurança corretos para a política SELinux da distribuição de destino.
A restauração do contexto é executada em duas fases, correspondendo à correção de propriedade:
+ **Fase 1**: restaura contextos em caminhos críticos (`~/.ssh/`,`~/.config/`) durante o provisionamento.
+ **Fase 2**: restaura contextos em todo o diretório inicial em segundo plano após a reinicialização.
### Correção automática do diretório inicial do RFC 2307
O Active Directory oferece suporte aos atributos RFC 2307 (também conhecidos como “Atributos Unix”), que permitem aos administradores especificar propriedades do usuário POSIX, incluindo o caminho do diretório inicial (). `unixHomeDirectory` O SSSD respeita esse atributo, enquanto o Winbind no AL2 o ignorou e sempre o usou. `/home/{{username}}`
Ao migrar do AL2 para uma SSSD-based distribuição, o objeto de usuário do AD pode ter sido `unixHomeDirectory` definido para um caminho diferente (por exemplo,`/home/CORP/jsmith`). Nesse caso, o SSSD resolve o diretório inicial do usuário para esse AD-specified caminho. Como os dados reais do usuário são `/home/{{username}}` da era AL2, o AD-specified caminho não existe no volume.
O sistema de migração detecta essa situação automaticamente:
1. Após o provisionamento, o SSSD resolve o diretório inicial do usuário para o caminho. AD-specified
1. O sistema de migração verifica se esse caminho existe no volume do usuário.
1. Se o AD-specified caminho não existir, mas existir, `/home/{{username}}` o sistema reconhecerá isso como uma incompatibilidade de caminho do RFC 2307.
1. O sistema se conecta `override_homedir=/home/%u` diretamente `/etc/sssd/sssd.conf` (em todas as seções do domínio) e reinicia o SSSD.
1. Depois que o SSSD é reiniciado, o diretório inicial do usuário é resolvido para`/home/{{username}}`, onde os dados realmente residem.
1. A migração prossegue normalmente em relação aos dados existentes.
Essa correção é permanente — a `override_homedir` configuração persiste em `sssd.conf` todas as reinicializações e futuras reinicializações do SSSD.
### Ativando os caminhos do diretório inicial do RFC 2307 após a migração
Se a migração corrigiu automaticamente o caminho do diretório inicial do RFC 2307 e você quiser que o SSSD respeite o `unixHomeDirectory` atributo AD daqui para frente, você poderá reverter a substituição. Essa é uma alteração de configuração avançada que só deve ser realizada se você entender as implicações.
**Atenção**
Depois de remover a substituição, o SSSD usará o caminho do diretório AD-specified inicial. Você deve mover os dados do usuário para esse caminho antes de remover a substituição, ou o usuário receberá um diretório inicial vazio.
Para restaurar os caminhos do diretório inicial do RFC 2307:
**Etapa 1: Determinar o caminho do diretório AD-specified inicial**
```
# Query the AD unixHomeDirectory attribute
ldapsearch -H ldap://your-dc.example.com -b "dc=example,dc=com" \
"(sAMAccountName=jsmith)" unixHomeDirectory
```
**Etapa 2: mover os dados do usuário para o AD-specified caminho**
```
sudo mkdir -p /home/CORP
sudo mv /home/jsmith /home/CORP/jsmith
```
**Etapa 3: remover a configuração override\_homedir de /sssd.conf etc/sssd**
```
sudo sed -i '/^override_homedir/d' /etc/sssd/sssd.conf
```
**Etapa 4: reiniciar o SSSD**
```
sudo systemctl restart sssd
```
**Etapa 5: Verificar se o diretório inicial foi resolvido corretamente**
```
getent passwd jsmith
# Should show /home/CORP/jsmith as the home directory
```
**Importante**
Depois de remover a substituição, futuras WorkSpace reconstruções e migrações usarão o caminho. AD-specified Certifique-se de que os dados estejam no local correto antes da próxima reconstrução ou migração.
### Notificações ao usuário
O sistema de migração usa dois mecanismos de notificação para manter o usuário informado:
1. **Notificações do serviço systemd da fase 2** — Se o usuário estiver conectado ao desktop quando a fase 2 for iniciada ou concluída, ele verá as notificações diretamente do serviço:
+ **Na Fase 2, comece:** “Concluindo a migração de arquivos em segundo plano. Você pode continuar trabalhando normalmente. Alguns arquivos podem permanecer inacessíveis até que a migração seja concluída.”
+ **Na conclusão da Fase 2:** “A migração do arquivo foi concluída com êxito. Todos os arquivos agora devem ter a propriedade correta. Consulte \~/workspace-migration-log-\* para obter detalhes.”
1. **Notificação de login de início automático do XDG** — Uma entrada de inicialização automática (`~/.config/autostart/ws-migration-notify.desktop`) é executada `/usr/lib/skylight/check-migration-status` no primeiro login após a migração. Isso trata do caso em que o usuário se conecta enquanto a Fase 2 ainda está em execução ou depois de já ter sido concluída:
+ **Se a Fase 2 ainda estiver em execução:** “A migração de arquivos está sendo executada em segundo plano. Você pode continuar trabalhando normalmente. Alguns arquivos podem permanecer inacessíveis até que a migração seja concluída.”
+ **Se a Fase 2 tiver sido concluída:** “A migração do arquivo foi concluída com êxito. Todos os arquivos agora devem ter a propriedade correta. Consulte \~/workspace-migration-log-\* para obter detalhes.”
A entrada de início automático é removida após a exibição da notificação de conclusão para que não seja executada em logins subsequentes.
Se o usuário não estiver conectado (por exemplo, uma parada automática WorkSpace que não tenha sido acessada), a Fase 2 será executada silenciosamente sem erros.
## Migração entre distribuições modernas
As migrações entre as distribuições Ubuntu, RHEL e Rocky Linux não exigem correção de propriedade do ID do usuário. Todas essas distribuições usam SSSD para integração com o Active Directory, que atribui IDs de usuário estáveis derivadas do AD SID. Os arquivos do usuário mantêm a propriedade correta durante a migração.
Os caminhos de migração comuns nessa categoria incluem:
+ **Cross-family:** Ubuntu 22.04 ↔ RHEL 8/9, Ubuntu 22.04 ↔ Rocky, RHEL ↔ Rocky 8/9
+ **Atualizações de versão:** Ubuntu 22.04 → Ubuntu 24.04, RHEL 8 → RHEL 9, Rocky 8 → Rocky 9
+ **Pacotes gráficos:** Qualquer fonte → Gráficos do Ubuntu 22.04. O Ubuntu Graphics também WorkSpaces pode migrar para qualquer destino que não seja gráfico.
Para migrações para destinos RHEL ou Rocky Linux, a restauração do contexto do SELinux sempre é executada para garantir que os arquivos tenham os rótulos de segurança corretos para a política SELinux da distribuição de destino. Isso se aplica independentemente da distribuição da fonte. Para arquivos que já têm rótulos corretos, a restauração é autônoma.
## O que os usuários mantêm e quais mudanças
### O que é preservado
+ Todos os arquivos no diretório inicial (Documentos, Downloads, Desktop e assim por diante)
+ Chaves SSH e configuração () `~/.ssh/`
+ Configuração do shell (`.bashrc`,`.profile`,`.bash_profile`)
+ Favoritos e perfis do navegador (Firefox, Chrome)
+ Application-specific dados e configuração (exceto componentes de desktop MATE em migrações de AL2)
### O que muda
+ O ambiente de desktop é redefinido para a aparência padrão do GNOME 3.x na distribuição de destino.
+ As preferências de desktop antigas do MATE são removidas e salvas em backup (somente migrações de AL2).
+ Os ícones da área de trabalho e as personalizações do painel são redefinidos para os padrões.
+ Os aplicativos instalados no volume raiz são substituídos pelos aplicativos padrão do pacote de destino. Os aplicativos instalados pelo usuário em seu diretório inicial são preservados.
## Auto-stop e sempre ativo WorkSpaces
### Auto-stop WorkSpaces
Para WorkSpaces configurar com parada automática (hibernação após o tempo limite de inatividade):
1. A migração é concluída e as WorkSpace reinicializações.
1. O serviço em segundo plano da Fase 2 começa na inicialização. Se o SSSD ainda não estiver pronto, o serviço tentará novamente a resolução do usuário por até 10 minutos antes de continuar.
1. Se o usuário não se conectar dentro do tempo limite de inatividade (normalmente 1 hora), a Fase 2 será executada silenciosamente em segundo plano.
1. Para cargas de trabalho típicas (menos de 100.000 arquivos), a Fase 2 é concluída dentro do tempo limite de inatividade.
1. Ele WorkSpace hiberna após a conclusão da Fase 2.
1. Na próxima vez que o usuário se conectar, a migração já estará concluída e nenhuma notificação será exibida.
### Always-on WorkSpaces
Para quem está sempre ligado WorkSpaces:
1. A migração é concluída e as WorkSpace reinicializações.
1. O serviço em segundo plano da Fase 2 começa na inicialização e é executado até a conclusão.
1. O usuário pode se conectar a qualquer momento e trabalhar normalmente — a fase 2 é executada com prioridade ociosa e não afeta o desempenho.
## Limitações conhecidas
+ **Active Directory Forest Trust:** O SSSD não oferece suporte a relacionamentos de Forest Trust. WorkSpaces em diretórios com o Forest Trust configurado não podem ser migrados.
+ **Amazon Linux 2 como alvo: o** AL2 chegou ao fim da vida útil e não é uma meta de migração válida. Você só pode migrar *do* AL2, não *para* o AL2.
+ **Sem reversão:** as migrações concluídas não podem ser revertidas para o sistema operacional anterior. Se precisar retornar ao sistema operacional anterior, inicie uma nova migração (exceto para o AL2, que não é um destino válido).
+ **Personalizações da área de trabalho do MATE:** Ao migrar do AL2, as preferências da área de trabalho do MATE são removidas. Eles são copiados`~/workspace-migration-log-YYYYMMDD/removed-configuration/`, mas não podem ser aplicados automaticamente ao desktop GNOME 3.x.
+ **Diretórios pessoais grandes:** para diretórios pessoais com milhões de arquivos, a correção da propriedade em segundo plano da Fase 2 pode levar várias horas. O usuário pode trabalhar normalmente durante esse período, mas alguns arquivos podem ter propriedade incorreta até a conclusão da Fase 2.
+ **Compartilhamento de arquivos:** se o usuário configurou o compartilhamento de arquivos (por exemplo, compartilhamentos do Samba) em seu diretório inicial, a mudança de propriedade durante a migração do AL2 pode afetar as permissões de compartilhamento. Talvez seja necessário restabelecer as configurações de compartilhamento de arquivos após a migração.
+ **Substituição do RFC 2307:** se a migração corrigiu automaticamente uma incompatibilidade do caminho do diretório inicial do RFC 2307, o atributo AD será substituído via in. `unixHomeDirectory` `override_homedir` `sssd.conf` Veja [Ativando os caminhos do diretório inicial do RFC 2307 após a migração](#linux-migration-al2-rfc2307-reverse) se você quer que o SSSD honre o AD-specified caminho.
## Solução de problemas
### A migração falha durante o provisionamento
Se a migração falhar e ela WorkSpace retornar ao `ERROR` estado, o plano de controle tentará restaurar automaticamente o original WorkSpace. Verifique os registros de provisionamento:
```
# Connect to the WorkSpace (if accessible) and check the domain-join log
sudo cat /var/log/skylight/domain-join.log
```
Causas comuns:
+ **Forest Trust configurado:** o SSSD não pode ingressar em um domínio com o Forest Trust. Remova o Forest Trust antes de migrar.
+ **Problemas de conectividade do AD:** WorkSpace não é possível acessar o controlador de domínio. Verifique as regras da rede VPC e do grupo de segurança.
+ **Falha na resolução de DNS:** WorkSpace não é possível resolver o domínio AD. Verifique a configuração do DNS.
### O usuário não consegue fazer login após a migração
+ Verifique se WorkSpace está no `AVAILABLE` estado.
+ Verifique se a adesão ao domínio foi concluída com êxito: `sudo cat /var/lib/skylight/domain-join-status` deve conter`true`.
+ Verifique se o usuário pode ser resolvido: `id {{username}}` deve retornar o UID e os grupos do usuário.
+ Verifique o status do SSSD: `sudo sssctl domain-status {{domain}}` deve aparecer`Online status: Online`.
### A área de trabalho parece quebrada ou tem o tema errado
Isso geralmente ocorre ao migrar do AL2 e alguns arquivos de configuração do MATE não foram limpos. Para redefinir a área de trabalho para os padrões:
```
# Remove remaining desktop configuration
rm -rf ~/.config/dconf/user
rm -rf ~/.gconf
# Log out and log back in
```
### Os arquivos têm propriedade errada após a migração
Se os arquivos no diretório inicial estiverem inacessíveis após uma migração de AL2, a Fase 2 ainda poderá estar em execução:
```
# Check Phase 2 status
systemctl is-active ws-migrate-phase2.service 2>/dev/null
# Check the migration log for progress
cat ~/workspace-migration-log-*/user-id-migration.txt
```
Se a Fase 2 tiver sido concluída, mas alguns arquivos ainda tiverem propriedade incorreta, você poderá corrigi-los manualmente:
```
# Find files with the old UID and change ownership
sudo find /home/{{username}} -uid {{old-uid}} -exec chown {{username}} {} +
sudo find /home/{{username}} -gid {{old-gid}} -exec chgrp {{username}} {} +
```
### Locais de arquivos de log
| Log | Local | Conteúdo |
| --- | --- | --- |
| Registro de ingresso no domínio | /var/log/skylight/domain-join.log | Fluxo de trabalho de provisionamento completo, incluindo a fase 1 de migração |
| Resumo da migração | \~/workspace-migration-log-YYYYMMDD/user-id-migration.txt | Old/new UIDs, contagens de arquivos, registros de data e hora para a Fase 1 e a Fase 2 |
| Backed-up Configurações do MATE | \~/workspace-migration-log-YYYYMMDD/removed-configuration/ | Arquivos de desktop MATE removidos durante a migração de AL2 |
| Lista de arquivos da fase 1 | \~/workspace-migration-log-YYYYMMDD/phase1-processed-files.txt | Arquivos processados durante a Fase 1 (usados pela Fase 2 para ignorar duplicatas) |