Migrar un Linux WorkSpace a un sistema operativo diferente

Puede migrar un Linux existente WorkSpace a un paquete de sistema operativo Linux diferente y, al mismo tiempo, conservar el directorio principal, los archivos y los datos del usuario. La migración reemplaza el volumen raíz (sistema operativo) por un paquete nuevo y, al mismo tiempo, mantiene intacto el volumen de usuario (/home). Esto es diferente de una reconstrucción, que actualiza el volumen raíz con el mismo paquete de sistema operativo.

La WorkSpace función Migrate gestiona todo el proceso de forma automática, incluida la corrección de la propiedad de los archivos y la limpieza del entorno de escritorio cuando es necesario.

Rutas de migración compatibles

La siguiente tabla muestra los sistemas operativos de origen y destino compatibles para la WorkSpace migración a Linux.

SO de origen	Ubuntu 22.04	Gráficos de 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 de Ubuntu 22.04	✓	—	✓	✓	✓	✓	✓
Ubuntu 24.04	✓	✓	—	✓	✓	✓	✓
RHEL 8	✓	✓	✓	—	✓	✓	✓
RHEL 9	✓	✓	✓	✓	—	✓	✓
Rocky 8	✓	✓	✓	✓	✓	—	✓
Rocky 9	✓	✓	✓	✓	✓	✓	—

Amazon Linux 2 es una fuente de migración válida, pero no un destino de migración válido. Amazon Linux 2 ha llegado al final de su vida útil y WorkSpaces no se pueden crear nuevos paquetes con AL2.

Todas las rutas de migración entre Ubuntu, RHEL y Rocky Linux son compatibles en ambas direcciones. Puede actualizar (por ejemplo, RHEL 8 → RHEL 9) o degradar (por ejemplo, Ubuntu 24.04 → Ubuntu 22.04). También puede migrar entre familias de distribución (por ejemplo, Rocky 9 → Ubuntu 24.04 o RHEL 9 → Rocky 8). La única restricción es que no se puede migrar WorkSpace al mismo paquete que ya está utilizando.

Las migraciones desde Amazon Linux 2 requieren la corrección automática de la propiedad del ID de usuario y la limpieza del entorno de escritorio. Las migraciones entre todas las demás distribuciones (Ubuntu, RHEL, Rocky) no requieren una corrección de propiedad, ya que todas estas distribuciones utilizan SSSD para la integración con Active Directory, que asigna identificadores de usuario estables.

Requisitos previos

Antes de migrar un Linux, compruebe lo siguiente: WorkSpace

• WorkSpace estado: WorkSpace debe estar en el AVAILABLE estado. No se puede migrar un WorkSpace elemento que se esté iniciando, deteniendo o en estado de error.

• Sin confianza en los bosques de Active Directory: el WorkSpace directorio no debe tener configuradas las relaciones de confianza en los bosques. El SSSD, que utilizan todas las distribuciones de Linux modernas para la integración con Active Directory, no es compatible con Forest Trust. Si Forest Trust está configurado, la migración fallará durante el aprovisionamiento.

• Almacenamiento de EBS suficiente: WorkSpace debe tener suficiente almacenamiento de EBS para la operación de migración.

¿Cómo migrar un WorkSpace

Uso de AWS Consola de administración

1. Abre la WorkSpaces consola de Amazon en https://console.aws.amazon.com/workspaces/.

2. En el panel de navegación, elija WorkSpaces.

3. Selecciona WorkSpace lo que deseas migrar.

4. Selecciona Acciones y, a continuación, selecciona Migrar WorkSpace.

5. Seleccione el paquete de sistema operativo de destino.

6. Seleccione Migrar.

Uso de AWS CLI

Utilice el migrate-workspace comando para WorkSpace migrar un paquete a otro:

aws workspaces migrate-workspace \
    --source-workspace-id ws-1234567890abcdef0 \
    --bundle-id wsb-jttwgmx20 \
    --region us-east-1

Para encontrar los ID de los paquetes de destino disponibles:

aws workspaces describe-workspace-bundles \
    --query 'Bundles[?contains(Name, `Ubuntu`) || contains(Name, `Rocky`) || contains(Name, `RHEL`)].{Name:Name,BundleId:BundleId}' \
    --output table

Supervisión del estado de la migración

La migración suele tardar entre 20 y 30 minutos. Supervise el estado WorkSpace:

aws workspaces describe-workspaces \
    --workspace-ids ws-1234567890abcdef0 \
    --query 'Workspaces[0].State' \
    --output text

La WorkSpace transición pasa por los siguientes estados: AVAILABLE → PENDING → AVAILABLE (en caso de éxito) o ERROR (en caso de error). Si la migración falla durante el aprovisionamiento, el plano de control restaura automáticamente el original WorkSpace.

Post-migration verificación

Una vez completada la migración, compruebe lo siguiente:

Compruebe el WorkSpace estado

Confirme WorkSpace que está en AVAILABLE estado en la AWS consola o mediante la CLI.

Verifique el inicio de sesión del usuario

Haga que el usuario inicie sesión WorkSpace y confirme que el escritorio se carga correctamente.

Compruebe el registro de migración

En el caso de las migraciones de AL2, revise el registro de migración para obtener detalles sobre los cambios:

cat ~/workspace-migration-log-*/user-id-migration.txt

Este registro muestra los ID de usuario antiguos y nuevos, el número de archivos modificados en cada fase y las marcas de tiempo.

Compruebe el estado de la fase 2

Para comprobar si la migración en segundo plano se ha completado:

# 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)

Qué ocurre durante la migración

Al iniciar una migración, se llevan a cabo los siguientes pasos:

1. El volumen de usuarios (/home) está separado del existente WorkSpace.

2. WorkSpace Se elimina lo existente.

3. WorkSpace Se crea uno nuevo a partir del paquete del sistema operativo de destino.

4. El volumen de usuarios se vuelve a adjuntar a la nueva WorkSpace dirección/home.

5. WorkSpace Se aprovisiona lo nuevo: se configura la red, la instancia se une a Active Directory y se configura el directorio principal del usuario.

6. Si se migra desde Amazon Linux 2, se corrige la propiedad del archivo y se limpia la configuración de escritorio antigua (consulteMigración desde Amazon Linux 2).

7. Se WorkSpace reinicia y queda disponible para que el usuario inicie sesión.

El directorio principal del usuario se almacena en un volumen de EBS independiente que se conserva durante la migración. Todos los archivos que contiene /home/username sobreviven a la transición, incluidos los documentos, las claves SSH, la configuración del shell y los datos de la aplicación.

Migración desde Amazon Linux 2

Las migraciones desde Amazon Linux 2 implican pasos adicionales que se gestionan automáticamente. En esta sección se explica qué ocurre y por qué.

Por qué las migraciones de AL2 son diferentes

Amazon Linux 2 utiliza Winbind para la integración con Active Directory, mientras que todas las distribuciones de Linux más recientes (Ubuntu, RHEL, Rocky) utilizan SSSD. Estos dos sistemas asignan distintos ID de usuario POSIX al mismo usuario de Active Directory:

• Winbind (AL2): asigna los ID de usuario mediante un esquema algorítmico impredecible (por ejemplo, el UID 1000).

• SSSD (distribuciones modernas): asigna identificadores de usuario estables derivados del SID de Active Directory (por ejemplo, el UID 1285401133).

Tras la migración, todos los archivos del directorio principal del usuario pertenecen al antiguo UID de Winbind. El usuario no puede acceder a sus propios archivos hasta que se corrija la propiedad para que coincida con el nuevo UID de SSSD.

Además, Amazon Linux 2 utiliza el entorno de escritorio MATE (GNOME 2), mientras que las distribuciones más recientes utilizan GNOME 3.x. Los archivos de configuración de MATE entran en conflicto con los de GNOME 3.x y deben limpiarse para garantizar que el escritorio funcione.

Two-phase corrección de propiedad

Para evitar los tiempos de espera del aprovisionamiento, la corrección de la propiedad se divide en dos fases.

Fase 1 (durante el aprovisionamiento)

Corrige la propiedad de los archivos críticos de escritorio necesarios para el inicio de sesión inmediato:

• El directorio principal en sí

• Claves SSH () ~/.ssh/

• Configuración de escritorio () ~/.config/

• Perfiles de carcasa (.bashrc,.bash_profile,.profile)

• Cualquier archivo o directorio de nivel superior sin permiso de lectura mundial

La fase 1 se completa rápidamente, independientemente del tamaño total del directorio principal, lo que garantiza que el aprovisionamiento nunca falle debido al gran tamaño de los directorios principales.

Fase 2 (en segundo plano, tras el reinicio)

Corrige la propiedad de todos los archivos restantes:

• Se ejecuta como un servicio systemd (ws-migrate-phase2.service) al arrancar

• Reintenta la resolución de usuario durante un máximo de 10 minutos si el SSSD aún no está listo en el arranque; si se agota el tiempo de espera de la resolución, el servicio permanece activado y lo vuelve a intentar en el siguiente arranque

• Utiliza la prioridad de inactividad y la I/O prioridad de CPU más baja, lo que no afecta a la experiencia del usuario

• El usuario puede iniciar sesión y trabajar con normalidad mientras se ejecuta la fase 2

• Las correcciones de propiedad de los directorios de gran tamaño (más de 10 millones de archivos) seguirán realizándose en segundo plano

• Self-removes el archivo de servicio systemd una vez finalizado correctamente

Limpieza del entorno de escritorio

Durante la migración desde AL2, los siguientes archivos de configuración de escritorio MATE se mueven a un directorio de respaldo dentro del registro de migración ()~/workspace-migration-log-YYYYMMDD/removed-configuration/:

• ~/.config/dconf/user— base de MATE-specific datos dconf

• ~/.gconf/— Directorio GConf heredado

• ~/.config/mate-session/— Configuración de sesión MATE

• ~/.config/mate-panel/— Configuración del panel MATE

• ~/.local/share/mate-panel/— Datos de aplicación del panel MATE

• ~/.config/pluma/— Ajustes del editor de texto MATE

• ~/.config/caja/— Configuración del administrador de archivos MATE

• ~/.config/marco/— Configuración del administrador de ventanas MATE

• ~/.config/gtk-2.0/, ~/.config/gtk-3.0/ — Configuraciones de temas GTK

• ~/.local/share/recently-used.xbel— Lista de archivos recientes

Estos archivos no se eliminan, sino que se mueven al directorio de copias de seguridad y se pueden recuperar si es necesario. Tras la limpieza, el escritorio se carga con el aspecto predeterminado de GNOME 3.x.

Restauración del contexto de SELinux

Cuando el objetivo de la migración es RHEL o Rocky Linux, los contextos de seguridad de SELinux siempre se restauran en todo el directorio principal del usuario (/home/username), independientemente del sistema operativo de origen. Esto se aplica a todas las rutas de migración que se dirigen a una SELinux-enabled distribución, incluidas las siguientes:

• Migraciones desde fuentes ajenas a SELinux (Ubuntu, AL2), donde los archivos carecen por completo de las etiquetas de SELinux.

• Migraciones entre SELinux-enabled distribuciones (por ejemplo, RHEL 8 → RHEL 9, Rocky 8 → Rocky 9 o RHEL 9 → Rocky 9). Las versiones de las políticas de SELinux y las definiciones del contexto de los archivos pueden cambiar entre las versiones principales.

En todos los casos, la restauración del contexto garantiza que los archivos tengan las etiquetas de seguridad correctas para la política de SELinux de la distribución de destino.

La restauración del contexto se lleva a cabo en dos fases, coincidiendo con la corrección de propiedad:

• Fase 1: restaura los contextos en las rutas críticas (~/.ssh/,~/.config/) durante el aprovisionamiento.

• Fase 2: restaura los contextos de todo el directorio principal en segundo plano tras el reinicio.

Corrección automática del directorio principal según RFC 2307

Active Directory admite los atributos RFC 2307 (también conocidos como «atributos de Unix»), que permiten a los administradores especificar las propiedades de los usuarios de POSIX, incluida la ruta del directorio principal (). unixHomeDirectory SSSD respeta este atributo, mientras que Winbind en AL2 lo ignora y lo utiliza siempre. /home/username

Al migrar de AL2 a una SSSD-based distribución, es posible que el objeto de usuario de AD se haya unixHomeDirectory establecido en una ruta diferente (por ejemplo,). /home/CORP/jsmith En ese caso, SSSD resuelve el directorio principal del usuario en esa ruta. AD-specified Como los datos reales del usuario /home/username provienen de la era AL2, la AD-specified ruta no existe en el volumen.

El sistema de migración detecta esta situación automáticamente:

1. Tras el aprovisionamiento, el SSSD convierte el directorio principal del usuario en la AD-specified ruta.

2. El sistema de migración comprueba si esta ruta existe en el volumen de usuarios.

3. Si la AD-specified ruta no existe pero /home/username existe, el sistema la reconoce como una discordancia de rutas según la norma RFC 2307.

4. El sistema se instala override_homedir=/home/%u directamente /etc/sssd/sssd.conf (en todas las secciones del dominio) y reinicia el SSSD.

5. Una vez reiniciado el SSSD, el directorio principal del usuario pasa a ser el lugar donde se encuentran /home/username realmente los datos.

6. La migración se realiza normalmente a partir de los datos existentes.

Esta corrección es permanente: la override_homedir configuración se mantiene durante los sssd.conf reinicios y futuros reinicios de SSSD.

Habilitar las rutas del directorio principal según la norma RFC 2307 tras la migración

Si la migración corrigió automáticamente la ruta del directorio principal del RFC 2307 y quieres que SSSD respete el unixHomeDirectory atributo AD de ahora en adelante, puedes revertir la anulación. Se trata de un cambio de configuración avanzado que solo debe realizarse si se comprenden las implicaciones.

aviso

Tras eliminar la anulación, SSSD utilizará la ruta del directorio AD-specified principal. Debe mover los datos del usuario a esa ruta antes de eliminar la anulación o el usuario obtendrá un directorio principal vacío.

Para restaurar las rutas del directorio principal del RFC 2307:

Paso 1: Determine la ruta del directorio AD-specified principal

# Query the AD unixHomeDirectory attribute
ldapsearch -H ldap://your-dc.example.com -b "dc=example,dc=com" \
    "(sAMAccountName=jsmith)" unixHomeDirectory

Paso 2: Mueva los datos del usuario a la AD-specified ruta

sudo mkdir -p /home/CORP
sudo mv /home/jsmith /home/CORP/jsmith

Paso 3: Elimine la configuración override_homedir de /sssd.conf etc/sssd

sudo sed -i '/^override_homedir/d' /etc/sssd/sssd.conf

Paso 4: Reiniciar SSSD

sudo systemctl restart sssd

Paso 5: Compruebe que el directorio principal se resuelva correctamente

getent passwd jsmith
# Should show /home/CORP/jsmith as the home directory

importante

Tras eliminar la anulación, las futuras WorkSpace recompilaciones y migraciones utilizarán la ruta. AD-specified Asegúrese de que los datos estén en la ubicación correcta antes de la próxima reconstrucción o migración.

Notificaciones de usuario

El sistema de migración utiliza dos mecanismos de notificación para mantener informado al usuario:

1. Notificaciones del servicio systemd de la fase 2: si el usuario está conectado al escritorio cuando se inicia o finaliza la fase 2, verá las notificaciones directamente desde el servicio:

   • En la fase 2, comience: «Completar la migración de archivos en segundo plano». Puede seguir trabajando con normalidad. Es posible que algunos archivos permanezcan inaccesibles hasta que finalice la migración».

   • Al finalizar la fase 2: «La migración de archivos se completó correctamente. Todos los archivos deberían tener ahora la propiedad correcta. Consulte ~/workspace-migration-log-* para obtener más información».

2. Notificación de inicio de sesión de inicio automático de XDG: se ejecuta una entrada de inicio automático () al iniciar sesión por primera vez después de la migración. ~/.config/autostart/ws-migration-notify.desktop /usr/lib/skylight/check-migration-status Esto soluciona el caso en el que el usuario se conecta mientras la fase 2 aún está en ejecución o cuando ya se ha completado:

   • Si la fase 2 sigue ejecutándose: «La migración de archivos se está ejecutando en segundo plano. Puede seguir trabajando con normalidad. Es posible que algunos archivos permanezcan inaccesibles hasta que finalice la migración».

   • Si la fase 2 se ha completado: «La migración de archivos se ha completado correctamente. Todos los archivos deberían tener ahora la propiedad correcta. Consulte ~/workspace-migration-log-* para obtener más información».

   La entrada de inicio automático se elimina después de mostrar la notificación de finalización para que no se ejecute en los siguientes inicios de sesión.

Si el usuario no está conectado (por ejemplo, una parada automática a la WorkSpace que no se ha accedido), la fase 2 se ejecuta de forma silenciosa y sin errores.

¿Migración entre distribuciones modernas

Las migraciones entre las distribuciones de Ubuntu, RHEL y Rocky Linux no requieren la corrección de la propiedad del ID de usuario. Todas estas distribuciones utilizan SSSD para la integración con Active Directory, que asigna identificadores de usuario estables derivados del SID de AD. Los archivos del usuario conservan la propiedad correcta durante toda la migración.

Entre las rutas de migración habituales de esta categoría se incluyen las siguientes:

• Cross-family: Ubuntu 22.04 ↔ RHEL 8/9, Ubuntu 22.04 ↔ Rocky 8/9, RHEL ↔ Rocky

• Actualizaciones de versión: Ubuntu 22.04 → Ubuntu 24.04, RHEL 8 → RHEL 9, Rocky 8 → Rocky 9

• Paquetes de gráficos: cualquier fuente → Ubuntu 22.04 Graphics. Ubuntu Graphics también WorkSpaces puede migrar a cualquier destino que no sea gráfico.

En el caso de las migraciones a destinos de RHEL o Rocky Linux, la restauración del contexto de SELinux siempre se ejecuta para garantizar que los archivos tengan las etiquetas de seguridad correctas según la política de SELinux de la distribución de destino. Esto se aplica independientemente de la distribución de origen. En el caso de los archivos que ya tienen las etiquetas correctas, la restauración no es necesaria.

Qué conservan los usuarios y qué cambios

¿Qué se conserva

• Todos los archivos del directorio principal (documentos, descargas, escritorio, etc.)

• Claves y configuración SSH () ~/.ssh/

• Configuración de shell (.bashrc,.profile,.bash_profile)

• Marcadores y perfiles del navegador (Firefox, Chrome)

• Application-specific datos y configuración (excepto los componentes de escritorio MATE en las migraciones de AL2)

¿Qué cambia

• El entorno de escritorio se restablece a la apariencia predeterminada de GNOME 3.x en la distribución de destino.

• Se eliminan las preferencias de escritorio antiguas de MATE y se realiza una copia de seguridad (solo en las migraciones de AL2).

• Los iconos del escritorio y las personalizaciones de los paneles se restablecen a sus valores predeterminados.

• Las aplicaciones instaladas en el volumen raíz se sustituyen por las aplicaciones predeterminadas del paquete de destino. Las aplicaciones instaladas por el usuario en su directorio principal se conservan.

Auto-stop y siempre activas WorkSpaces

Auto-stop WorkSpaces

Para WorkSpaces configurar con parada automática (hibernación después de un tiempo de espera de inactividad):

1. La migración se completa y se reinicia. WorkSpace

2. El servicio en segundo plano de la fase 2 se inicia al arrancar. Si el SSSD aún no está listo, el servicio vuelve a intentar la resolución por parte del usuario durante un máximo de 10 minutos antes de continuar.

3. Si el usuario no se conecta durante el tiempo de espera de inactividad (normalmente 1 hora), la fase 2 se ejecuta silenciosamente en segundo plano.

4. En el caso de las cargas de trabajo habituales (menos de 100 000 archivos), la fase 2 finaliza dentro del tiempo de espera de inactividad.

5. WorkSpace Hiberna una vez finalizada la fase 2.

6. La próxima vez que el usuario se conecte, la migración ya se habrá completado y no se mostrará ninguna notificación.

Always-on WorkSpaces

Para estar siempre conectado: WorkSpaces

1. La migración se completa y se reinicia WorkSpace .

2. El servicio en segundo plano de la fase 2 se inicia al arrancar y se ejecuta hasta su finalización.

3. El usuario puede conectarse en cualquier momento y trabajar con normalidad: la fase 2 se ejecuta con prioridad de inactividad y no afecta al rendimiento.

Limitaciones conocidas

• Active Directory Forest Trust: el SSSD no admite las relaciones de confianza en los bosques. WorkSpaces en directorios con Forest Trust configurado, no se pueden migrar.

• Amazon Linux 2 como objetivo: AL2 ha llegado al final de su vida útil y no es un objetivo de migración válido. Solo puede migrar de AL2, no a AL2.

• Sin reversión: las migraciones completadas no se pueden revertir al sistema operativo anterior. Si necesita volver al sistema operativo anterior, debe iniciar una nueva migración (excepto para el AL2, que no es un destino válido).

• Personalizaciones de escritorio MATE: al migrar desde AL2, se eliminan las preferencias de escritorio de MATE. Están respaldadas, ~/workspace-migration-log-YYYYMMDD/removed-configuration/ pero no se pueden aplicar automáticamente al escritorio GNOME 3.x.

• Directorios principales de gran tamaño: en el caso de los directorios principales con millones de archivos, la segunda fase de corrección de la propiedad en segundo plano puede tardar varias horas. El usuario puede trabajar con normalidad durante este tiempo, pero es posible que algunos archivos tengan una propiedad incorrecta hasta que finalice la fase 2.

• Uso compartido de archivos: si el usuario ha configurado el uso compartido de archivos (por ejemplo, los recursos compartidos de Samba) en su directorio principal, el cambio de propiedad durante la migración a AL2 puede afectar a los permisos de uso compartido. Es posible que sea necesario restablecer las configuraciones de uso compartido de archivos tras la migración.

• Anulación de RFC 2307: si la migración corrige automáticamente una discordancia en la ruta del directorio principal de RFC 2307, el atributo AD se anula mediante in. unixHomeDirectory override_homedir sssd.conf Comprueba si quieres que SSSD respete la rutaHabilitar las rutas del directorio principal según la norma RFC 2307 tras la migración. AD-specified

Resolución de problemas

La migración falla durante el aprovisionamiento

Si la migración falla y WorkSpace vuelve al ERROR estado, el plano de control intentará restaurar automáticamente el original WorkSpace. Compruebe los registros de aprovisionamiento:

# Connect to the WorkSpace (if accessible) and check the domain-join log
sudo cat /var/log/skylight/domain-join.log

Causas habituales:

• Configuración de Forest Trust: el SSSD no puede unirse a un dominio con Forest Trust. Elimine Forest Trust antes de realizar la migración.

• Problemas de conectividad de AD: WorkSpace no pueden acceder al controlador de dominio. Compruebe las reglas de los grupos de seguridad y redes de VPC.

• Error de resolución de DNS: WorkSpace no se puede resolver el dominio AD. Compruebe la configuración de DNS.

El usuario no puede iniciar sesión después de la migración

• Compruebe que WorkSpace esté en AVAILABLE estado.

• Compruebe que la unión de dominio se haya completado correctamente: sudo cat /var/lib/skylight/domain-join-status debe contenertrue.

• Compruebe que el usuario se pueda resolver: id username debe devolver el UID y los grupos del usuario.

• Compruebe el estado del SSSD: sudo sssctl domain-status domain debería mostrarse. Online status: Online

El escritorio parece estar roto o tiene un tema incorrecto

Esto suele ocurrir al migrar desde AL2 y algunos archivos de configuración de MATE no se han limpiado. Para restablecer los valores predeterminados del escritorio:

# Remove remaining desktop configuration
rm -rf ~/.config/dconf/user
rm -rf ~/.gconf

# Log out and log back in

Los archivos tienen una propiedad incorrecta tras la migración

Si no se puede acceder a los archivos del directorio principal tras una migración a AL2, es posible que la fase 2 siga ejecutándose:

# 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

Si la fase 2 se ha completado, pero algunos archivos siguen teniendo una propiedad incorrecta, puede corregirlos 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 {} +

Ubicaciones de archivo de registro

Registro	Ubicación	Contenido
Registro de uniones de dominios	/var/log/skylight/domain-join.log	Flujo de trabajo de aprovisionamiento completo, incluida la fase 1 de migración
Resumen de la migración	~/workspace-migration-log-YYYYMMDD/user-id-migration.txt	Old/new UID, recuentos de archivos y marcas de tiempo para las fases 1 y 2
Backed-up Configuraciones MATE	~/workspace-migration-log-YYYYMMDD/removed-configuration/	Los archivos de escritorio MATE se eliminaron durante la migración a AL2
Lista de archivos de la fase 1	~/workspace-migration-log-YYYYMMDD/phase1-processed-files.txt	Archivos procesados durante la fase 1 (utilizados en la fase 2 para omitir los duplicados)