El Mac que te deja entrar y no te enseña nada

Un cliente abre su Mac en el navegador. La conexión funciona. El usuario y la contraseña se aceptan. Y la pantalla sale negra. Ni un error ni una desconexión. Negra, con un cursor que se mueve.

Todos los logs dicen que la máquina está bien. El servicio de Compartir Pantalla está en marcha. La cuenta se autentica. La sesión está desbloqueada. Disco, CPU y memoria, normales. Nada informa de ningún problema.

Esto nos costó varios días. Aquí va lo que era de verdad, y por qué las formas obvias de comprobarlo son peor que inútiles.

Todo lo obvio está mal

Un Mac sin pantalla que muestra negro tiene una lista conocida de sospechosos. Los revisamos todos.

• Sin pantalla conectada. El consejo habitual es un conector HDMI falso. Los compramos. Nada cambió.
• La resolución. Un Mac sin pantalla puede arrancar con un tamaño que a algunos clientes no les gusta. No era eso.
• El bloqueo de pantalla. Una sesión bloqueada puede mostrar negro. La sesión estaba desbloqueada.
• La propia pantalla. Conectamos un monitor real a un Mac mini real. La pantalla física también estaba negra.

Esto último fue lo que cambió el rumbo de la búsqueda. La máquina no fallaba al enviar una imagen a un cliente remoto. No había imagen.

Estar en marcha no es lo mismo que tener permiso

Nuestro script de aprovisionamiento activa Compartir Pantalla de la única forma que funciona sin una persona delante:

launchctl enable system/com.apple.screensharing
launchctl bootstrap system   /System/Library/LaunchDaemons/com.apple.screensharing.plist

Eso arranca el servicio. Desde macOS 14, el propio kickstart -activate de Apple se niega a funcionar sin pantalla, así que esto es lo que queda.

Pero arrancar el servicio no es lo mismo que darle permiso para grabar la pantalla. La grabación de pantalla es un privilegio de TCC. macOS lo concede exactamente de dos formas. Una persona activa Compartir Pantalla en Ajustes del Sistema y se autentica, o un MDM envía un perfil PPPC.

Sin ese permiso, el servicio sigue en marcha. Sigue escuchando en el puerto 5900. Sigue aceptando tu contraseña. Simplemente no tiene nada que le esté permitido enseñarte.

macOS te lo dice, si le haces la pregunta correcta:

$ sudo .../ARDAgent.app/Contents/Resources/kickstart     -configure -access -on -users runner -privs -all

Screen recording might be disabled. Screen Sharing or Remote
Management must be enabled from System Settings or via MDM.

Por qué no lo encontramos antes

Esta es la parte que vale la pena contar. El problema no era que la respuesta estuviera escondida. Era que todas las formas baratas de comprobarlo nos decían que todo iba bien.

screencapture por SSH siempre falla. Si lo ejecutas en una sesión SSH, TCC lo deniega, tenga o no el privilegio. No distingue una máquina rota de una que funciona, así que todo lo que nos devolvió era ruido.

La prueba con kickstart pasa cuando no tiene privilegios. Sin permisos suficientes no muestra nada. El código que trata una salida vacía como ausencia de aviso lo interpreta como un éxito. El nuestro lo hacía.

Las dos comprobaciones comparten una propiedad: su salida en caso de fallo es idéntica a su salida en caso de éxito. Una comprobación así no es una prueba débil. No es ninguna prueba, disfrazada de tranquilidad.

Mide la imagen

La única prueba fiable es lo que ve el cliente. Nos conectamos como un cliente VNC real, pedimos un rectángulo del framebuffer y lo medimos. Un escritorio negro son dos colores con un brillo casi nulo. Uno que funciona no.

desktop        : Mac mini  1920x1080  32bpp depth24
sampled        : 273768 pixels from 1 rect(s)
mean brightness: 36.31%
distinct colours: 93828
RESULT: REAL PICTURE

Noventa y tres mil colores distintos son un escritorio. Dos son un fallo. No hay nada que interpretar ni ningún código de salida que leer mal. Ahora esto se ejecuta en cada máquina antes de que un cliente se acerque a ella.

La solución, y lo que cuesta

En una máquina, la solución lleva diez segundos. Abre Ajustes del Sistema, General, Compartir. Desactiva Compartir Pantalla. Vuelve a activarlo. Te pide una contraseña de administrador, y esa autenticación es justo lo que importa. El interruptor suele aparecer ya activado, porque el script arrancó el servicio. Cambiarlo de todos modos es lo que concede el privilegio.

El permiso es a nivel de sistema, así que sobrevive al borrado de la máquina entre clientes. Lo comprobamos borrando una unidad y verificando otra vez.

El coste real es que necesita a una persona delante de la máquina, una vez. Es el único paso manual en un proceso por lo demás automatizado. A escala de flota, la respuesta es un perfil de configuración MDM que conceda el privilegio de antemano. Esa es la solución correcta. Y es lo único que no puedes resolver con un script en un Mac que todavía no has inscrito.

Si automatizas Mac

Hay dos lecciones que vale la pena llevarse, y solo una trata de la grabación de pantalla.

La primera es que macOS tiene una categoría de estado a la que un script no llega. Los privilegios de TCC están protegidos a propósito tras una persona en el teclado o un perfil MDM. Si tu automatización da por hecho que puede configurarlo todo, acabará produciendo una máquina que parece aprovisionada y no lo está.

La segunda es más general. Antes de escribir una comprobación, pregúntate qué muestra cuando la cosa está rota. Si coincide con lo que muestra cuando funciona, la comprobación no vale nada. Te costará más tiempo que no tener ninguna. Nosotros teníamos dos así, y son la razón de que esto llevara días en lugar de una tarde.