sudo-rs: «I'm afraid I can't do that» en Ubuntu 26.04

Qué significa «I'm afraid I can't do that» en sudo-rs

Si sudo en Ubuntu 26.04 te contesta «I'm afraid I can't do that», el fichero sudoers no autoriza a tu usuario para esa orden. Ubuntu 26.04 usa sudo-rs como sudo. sudo-rs usa esa frase de HAL 9000 para decir lo mismo que el sudo clásico decía con «is not in the sudoers file». El arreglo está en los grupos del usuario o en una regla de sudoers, y se hace desde una shell de root.

El informe del proyecto recoge el mensaje que ve el lector:

sudo: I'm sorry alice. I'm afraid I can't do that

La frase viene de la película 2001: Una odisea del espacio. A los desarrolladores les hace gracia. A quien acaba de actualizar un servidor de producción, bastante menos. Hay una petición abierta para cambiarla: la issue #1659 de sudo-rs, que se abrió el 26 de julio de 2026 y sigue sin cerrar a fecha de octubre de 2026. Por eso esta guía no se apoya en el texto. Puede que una versión futura diga otra cosa, pero la causa seguirá siendo la misma.

Autenticación y autorización: dos preguntas distintas

sudo hace dos comprobaciones antes de ejecutar nada. La primera es la autenticación: demostrar que eres quien dices ser, normalmente con tu contraseña. La segunda es la autorización: comprobar en /etc/sudoers y en /etc/sudoers.d/ si tu usuario puede ejecutar esa orden concreta como root.

El mensaje de HAL pertenece a la segunda. Aunque tu contraseña sea correcta, el resultado será el mismo, porque ninguna regla te da permiso. Cambiar la contraseña o reinstalar sudo-rs no sirve de nada. Lo que hay que cambiar es la lista de reglas o la lista de grupos del usuario.

Por qué aparece justo después de actualizar desde Ubuntu 24.04

En Ubuntu 24.04, sudo es la implementación clásica escrita en C. Ubuntu 26.04 instala sudo-rs, una reimplementación en Rust, y la pone en su lugar. El sudo clásico sigue disponible con el sufijo .ws (sudo.ws). El cambio forma parte de un plan más amplio, que se explica en la sustitución de herramientas básicas de Ubuntu por versiones en Rust.

Las dos implementaciones leen los mismos ficheros. Así que, después de actualizar de Ubuntu 24.04 a 26.04, el error suele tener una de estas dos causas:

1. El usuario nunca estuvo autorizado y el problema aparece ahora por casualidad. Por ejemplo, porque antes trabajabas siempre con otra cuenta.
2. El usuario tenía una regla que sudo-rs interpreta de otra forma. El caso típico es un comodín (*) en medio de los argumentos.

Paso 1: comprueba qué sudo se está ejecutando

Estas órdenes no necesitan privilegios, así que el usuario bloqueado puede ejecutarlas:

command -v sudo
readlink -f "$(command -v sudo)"
dpkg -S "$(readlink -f "$(command -v sudo)")"
sudo --version

command -v muestra qué fichero ejecuta tu shell cuando escribes sudo. readlink -f sigue los enlaces simbólicos hasta el fichero real, por si tu sistema usa el mecanismo de alternativas de Debian. dpkg -S dice qué paquete instaló ese fichero. Si el paquete es sudo-rs, esta guía es para ti. Si es sudo, estás usando la implementación clásica, que nunca muestra la frase de HAL.

sudo --version sirve como comprobación rápida, porque mostrar la versión no requiere autorización. Fíate más de dpkg -S. Nombra el paquete, y el paquete decide qué código se ejecuta.

Paso 2: ¿está el usuario en el grupo sudo?

En Ubuntu, la regla de administración habitual autoriza a todo el grupo sudo. Es la línea %sudo ALL=(ALL:ALL) ALL del fichero /etc/sudoers. El signo % indica que la regla se aplica a un grupo y no a un usuario. Comprueba los grupos con dos órdenes:

id
getent group sudo

id muestra los grupos del proceso actual, es decir, los de tu sesión. getent group sudo muestra los miembros que figuran en la base de datos de grupos. Si getent te incluye pero id no, alguien te añadió al grupo después de que iniciaras sesión. Linux asigna los grupos a un proceso cuando empieza la sesión, así que una sesión abierta conserva la lista antigua. Cierra la sesión SSH y abre una nueva. Después, id debería mostrar sudo en la lista.

Si ninguna de las dos órdenes te muestra en el grupo, el usuario no tiene permiso de administración. Necesitas una shell de root para dárselo.

Paso 3: consigue una shell de root sin depender de tu sudo

Si tienes otra cuenta con permisos de administración, entra con ella y ejecuta sudo -i. Si no la tienes, ve a la sección de recuperación al final de esta guía. A partir de aquí, todas las órdenes se ejecutan como root.

Reproduce el fallo con un usuario de prueba

Antes de tocar tu cuenta real, practica con una cuenta desechable. Así ves el fallo y el arreglo sin arriesgar nada:

useradd -m -s /bin/bash alice
id alice
runuser -u alice -- sudo -n true; echo "código de salida: $?"

useradd sin la opción -p crea la cuenta con la contraseña bloqueada. Nadie puede entrar como alice con una contraseña, y sudo no tiene nada que preguntarle. runuser ejecuta una orden como otro usuario sin pedir contraseña, porque lo invoca root. La opción -n de sudo significa «no interactivo»: si sudo necesita preguntar algo, falla en lugar de esperar.

El código de salida debe ser distinto de cero. Fíjate en ese número y no en el texto. Con -n, el texto puede no coincidir con el que ves en una sesión interactiva, y además puede cambiar en una versión futura. El código de salida no cambia: cero significa que la orden se ejecutó como root, y cualquier otro valor significa que no.

Para ver qué permite sudoers a un usuario, pregunta directamente como root:

sudo -l -U alice

-l lista los permisos y -U indica de qué usuario. Las dos opciones aparecen en la documentación de sudo-rs. Para alice, la salida no debe mostrar ninguna regla. Esta es la comprobación más útil, porque ves las reglas tal como sudo-rs las entiende, que puede no ser como tú crees que están escritas.

Arreglo 1: añade el usuario al grupo sudo

usermod -aG sudo alice
id alice
sudo -l -U alice

La a de -aG es importante. Significa «añadir». Sin ella, -G sustituye todos los grupos secundarios del usuario por la lista que escribes, y el usuario pierde, por ejemplo, el grupo docker. Después de ejecutarla, id alice debe incluir sudo y sudo -l -U alice debe mostrar la regla del grupo sudo.

Ahora runuser -u alice -- sudo -n true sigue fallando, y es lo correcto. alice ya está autorizada, pero la regla del grupo sudo exige contraseña y alice no tiene ninguna. Ahora el fallo es de autenticación: sudo quiere una contraseña que no puede pedir. Para un usuario real, define una contraseña con passwd nombre_de_usuario y pídele que abra una sesión nueva.

Arreglo 2: una regla sin contraseña para una sola orden

A veces no quieres dar permiso de administración completo. Por ejemplo, un usuario de despliegue solo necesita una orden concreta. Para eso sirve un fichero en /etc/sudoers.d/. Escríbelo primero fuera de ese directorio y compruébalo con visudo antes de instalarlo:

printf 'alice ALL=(root) NOPASSWD: /usr/bin/getent shadow alice\n' > /root/90-alice
chmod 0440 /root/90-alice
visudo -c -f /root/90-alice
install -m 0440 -o root -g root /root/90-alice /etc/sudoers.d/90-alice
visudo -c

visudo -c solo comprueba la sintaxis y no abre ningún editor. Con -f comprueba el fichero que le indicas. Las dos opciones aparecen en la documentación de sudo-rs. Compruebas antes de instalar porque un fichero con errores dentro de /etc/sudoers.d/ puede dejar sin sudo a todos los usuarios, también a ti. El nombre 90-alice no lleva punto. El sudo clásico ignora los ficheros de ese directorio cuyo nombre contiene un punto o termina en ~, y con un nombre sin punto el mismo fichero sirve para las dos implementaciones.

Ahora prueba la regla y después una orden que la regla no cubre:

runuser -u alice -- sudo -n /usr/bin/getent shadow alice
runuser -u alice -- sudo -n true; echo "código de salida: $?"

La primera orden debe imprimir la línea de alice del fichero /etc/shadow. Solo root puede leer ese fichero, así que la línea demuestra que la orden se ejecutó con privilegios. La segunda debe fallar con un código distinto de cero, porque ninguna regla autoriza true. Tener una regla no es lo mismo que tener todas. Este es el caso más confuso: sudo -l -U alice muestra una regla y, aun así, sudo-rs rechaza la orden.

Paso 4: la regla existe pero ya no coincide

Si sudo -l -U muestra una regla para el usuario y la orden falla de todos modos, compara la regla con la línea exacta que ejecuta el usuario. Puedes preguntar a sudo por una orden concreta:

sudo -l -U alice /usr/bin/getent shadow alice; echo "código de salida: $?"
sudo -l -U alice /usr/bin/getent shadow root; echo "código de salida: $?"

La primera debe terminar con código 0 y la segunda no. La regla dice shadow alice y sudo-rs compara cada argumento como texto literal, así que shadow root no coincide.

Esa comparación literal explica la mayoría de las reglas que dejan de funcionar después de la actualización. El sudo clásico aceptaba comodines en cualquier argumento. Dentro de la lista de argumentos, sudo-rs solo acepta un * como último argumento, con el sentido de «cualquier argumento que venga después». No repetimos aquí cómo reescribir esas reglas. Lo explica con detalle la guía sobre qué cambia con sudo-rs en Ubuntu, en la sección sobre comodines en sudoers.

¿Volver al sudo clásico arregla el error?

Casi nunca. sudo.ws lee el mismo /etc/sudoers y el mismo /etc/sudoers.d/. Un usuario que no tiene regla tampoco está autorizado allí. Solo cambia el mensaje: verás «is not in the sudoers file» en lugar de la frase de HAL. Volver atrás solo ayuda cuando la regla usa algo que sudo-rs no acepta, como un comodín en mitad de los argumentos.

Si es tu caso y necesitas tiempo para reescribir las reglas, sigue la sección sobre volver a sudo.ws de la guía de sudo-rs en Ubuntu 26.04. Trátalo como una solución temporal.

Limpia la prueba

Cuando termines con la cuenta de práctica, bórrala junto con su regla:

rm /etc/sudoers.d/90-alice /root/90-alice
userdel -r alice
visudo -c

visudo -c debe terminar sin errores. Si después quieres revisar quién ejecutó cada orden con sudo en el servidor, la guía para auditar las órdenes de los usuarios en tu servidor explica dónde quedan esos registros.

Si la única cuenta de administrador es la que está bloqueada

Este es el caso difícil. No hay otra cuenta con sudo, y en Ubuntu la cuenta root suele estar bloqueada sin contraseña. Tienes dos caminos, y los dos empiezan en el panel de tu proveedor.

La consola web del proveedor. La consola es una pantalla y un teclado virtuales conectados al servidor. Si root tiene contraseña, entra como root y ejecuta usermod -aG sudo tu_usuario. Si root no tiene contraseña, la consola no basta.

El modo de rescate. El servidor arranca desde un sistema temporal y tu disco queda disponible para montarlo. Los nombres de dispositivo cambian según el proveedor, así que primero localiza la partición raíz con lsblk. Este ejemplo usa /dev/vda1:

lsblk
mount /dev/vda1 /mnt
chroot /mnt
usermod -aG sudo tu_usuario
visudo -c
exit
umount /mnt

chroot hace que las órdenes siguientes trabajen sobre tu sistema y no sobre el de rescate. Así usermod modifica tu /etc/group. Después, sal del modo de rescate desde el panel y arranca el servidor de forma normal.

Si el problema es que el usuario ni siquiera existe, por ejemplo porque cloud-init no lo creó en el primer arranque, lee qué hacer cuando cloud-init no crea tu usuario y no puedes entrar. Si la actualización a 26.04 se quedó a medias, empieza por recuperar una actualización de Ubuntu fallida y vuelve aquí después.

Para la próxima vez, una costumbre evita casi todo esto. Antes de tocar sudoers o de actualizar la versión de Ubuntu, deja abierta una segunda sesión SSH con una shell de root. Si algo falla, lo arreglas desde esa sesión.

FAQ

¿Qué significa «I'm afraid I can't do that» cuando uso sudo en Ubuntu 26.04?

Significa que sudoers no autoriza a tu usuario para esa orden. Ubuntu 26.04 usa sudo-rs como sudo, y sudo-rs muestra esa frase de HAL 9000 donde el sudo clásico decía «is not in the sudoers file». El problema no es la contraseña. Desde una shell de root, añade el usuario al grupo sudo con usermod -aG sudo usuario, o crea una regla en /etc/sudoers.d/ y compruébala con visudo -c.

He añadido mi usuario al grupo sudo y sudo sigue fallando. ¿Por qué?

Tu sesión conserva los grupos que tenía al empezar. Linux asigna los grupos a un proceso al iniciar sesión, y usermod no cambia los procesos que ya están en marcha. Compara id, que muestra los grupos de tu sesión, con getent group sudo, que muestra la base de datos. Si solo apareces en la segunda, cierra la sesión SSH y abre una nueva.

¿Cómo veo qué reglas de sudoers tiene un usuario con sudo-rs?

Como root, ejecuta sudo -l -U usuario. Muestra las reglas tal como sudo-rs las interpreta. Para comprobar una orden concreta, añádela al final, por ejemplo sudo -l -U usuario /usr/bin/systemctl restart nginx, y mira el código de salida. Un 0 significa que la regla la cubre.

¿Si vuelvo a sudo.ws desaparece el error?

Solo si la regla usa algo que sudo-rs no acepta, como un comodín en mitad de los argumentos. sudo.ws lee los mismos ficheros sudoers, así que un usuario sin regla tampoco tiene permiso allí. Solo cambia el mensaje. Arregla la regla o los grupos del usuario.

¿Cómo recupero el acceso si la única cuenta con sudo es la bloqueada?

Usa el panel de tu proveedor. Si root tiene contraseña, entra por la consola web y ejecuta usermod -aG sudo tu_usuario. Si no la tiene, arranca en modo de rescate y monta la partición raíz que muestra lsblk. Después entra con chroot y ejecuta allí el mismo usermod. Al terminar, arranca el servidor de forma normal.