Problema

En entornos de archivos compartidos (SMB) es frecuente que procesos automáticos de ingestión y limpieza de datos dejen rastros de carpetas con ACLs corruptas, atributos de solo lectura, o bloqueos de procesos. Cuando un administrador intenta borrar esos recursos, el sistema devuelve Access denied incluso bajo cuentas con privilegios de Administrador local o incluso bajo el contexto SYSTEM. El síntoma típico es:

Access is denied.

Este bloqueo impide la rotación de datos, llena volúmenes y rompe pipelines de backup. El problema no es exclusivo de un servidor concreto; cualquier Windows Server que sirva como repositorio de ingestión masiva puede encontrarse con archivos que se resisten a ser eliminados por razones de permisos, herencia rota o manejadores abiertos.

Causa

Los bloqueos de eliminación suelen originarse en tres áreas:

  1. Permisos y herencia rotos

    • ACLs heredadas que fueron modificadas manualmente, dejando un owner desconocido.
    • Entradas de control de acceso (ACE) que niegan explícitamente Delete o Delete Subfolders and Files al grupo Administradores.

  2. Atributos de archivo

    • Read‑Only, System o Hidden marcados a nivel de archivo o carpeta.
    • Bit de Integrity (en volúmenes ReFS) que impide modificaciones sin privilegios de Integrity‑Control.

  3. Manejadores abiertos

    • Servicios o procesos que mantienen un handle abierto (por ejemplo, antivirus, indexadores, procesos de copia).
    • Locks de SMB que persisten después de que el cliente se desconecta, especialmente en sesiones de red con OpLocks activados.

En la práctica, la combinación de un owner extraño y una ACE que niega Delete es la más frecuente, y los intentos de takeown o icacls fallan porque el propio proceso no tiene permiso para modificar la ACL del objeto.

Solución

Una estrategia en varios pasos permite “resetear” el objeto y eliminarlo sin preguntar. La idea es:

  1. Obtener el control total del objeto usando takeown bajo el contexto SYSTEM.
  2. Restablecer la ACL a una lista mínima que garantice Full Control al Administrador y al grupo SYSTEM.
  3. Eliminar atributos problemáticos (Read‑Only, System).
  4. Forzar la eliminación con del /f /s /q o Remove‑Item -Recurse -Force en PowerShell.
  5. Opcional: usar PSExec para ejecutar los pasos bajo la cuenta SYSTEM si la sesión actual no tiene suficiente privilegio.

Paso a paso

  1. Ejecutar una consola como SYSTEM

    • Si ya tienes acceso a una cuenta con privilegios de SeDebugPrivilege, psexec -i -s cmd.exe abre una ventana bajo SYSTEM.
    • En entornos sin PsTools, usar el programador de tareas (schtasks /run /tn "ElevatedCmd").

  2. Tomar posesión

    takeown /F "D:\staging\problem_folder" /R /A
    • /A asigna la propiedad al grupo Administradores.
    • /R recorre subcarpetas.

  3. Restablecer ACL

    icacls "D:\staging\problem_folder" /reset /T /C
icacls "D:\staging\problem_folder" /grant:r "Administrators:(OI)(CI)F" "SYSTEM:(OI)(CI)F" /T /C
    • /reset elimina ACE personalizadas.
    • (OI)(CI)F otorga Full Control a objetos y contenedores.

  4. Eliminar atributos

    attrib -R -S -H "D:\staging\problem_folder\*" /S /D

  5. Forzar la eliminación

    del /F /S /Q "D:\staging\problem_folder\*"
rmdir /S /Q "D:\staging\problem_folder"

    O, si prefieres PowerShell (más tolerante a nombres largos):

    Remove-Item -LiteralPath "D:\staging\problem_folder" -Recurse -Force

  6. Limpiar bloqueos de SMB (si persisten)

    • Desactivar temporalmente OpLocks: fsutil behavior set disableoplocks 1 (requiere reinicio).
    • Reiniciar el servicio Server (net stop server && net start server) para liberar handles colgados.

Alternativas rápidas

  • Uso de Unlocker o Handle de Sysinternals para identificar y cerrar handles abiertos.
  • Reiniciar en modo seguro y ejecutar los mismos comandos; el arranque mínimo reduce la probabilidad de handles activos.
  • Mover la carpeta a un volumen NTFS sin restricciones y borrar allí; la operación de mover suele sobrescribir ACLs problemáticas.

Cuándo aplicar esta solución

  • Síntomas: Access is denied al intentar borrar, incluso como Administrador o SYSTEM; takeown devuelve error 5; icacls muestra “Failed to get security descriptor”.
  • Entorno: Windows Server (cualquier versión con NTFS), compartido vía SMB, con procesos automáticos que crean y limpian datos.
  • No aplica: Cuando el archivo está bloqueado por un proceso crítico que no puede ser detenido (por ejemplo, bases de datos en uso) o cuando el volumen está dañado (errores de CHKDsk). En esos casos, primero reparar el FS o detener el servicio que mantiene el lock.

Código

psexec -i -s cmd.exe
takeown /F "D:\staging\problem_folder" /R /A
icacls "D:\staging\problem_folder" /reset /T /C
icacls "D:\staging\problem_folder" /grant:r "Administrators:(OI)(CI)F" "SYSTEM:(OI)(CI)F" /T /C
attrib -R -S -H "D:\staging\problem_folder\*" /S /D
del /F /S /Q "D:\staging\problem_folder\*"
rmdir /S /Q "D:\staging\problem_folder"

Verificación

  1. Listar ACL después del paso 3:

    icacls "D:\staging\problem_folder"

    Debe mostrar Administrators y SYSTEM con (F).

  2. Comprobar atributos:

    attrib "D:\staging\problem_folder\*"

    Ningún atributo R, S o H debería aparecer.

  3. Confirmar ausencia de la carpeta:

    if exist "D:\staging\problem_folder" (echo "Falla") else (echo "Éxito")

  4. Revisar handles (opcional):

    handle -a | findstr /i "problem_folder"

    No debe aparecer ninguna entrada.

Notas adicionales

  • Precaución con takeown /A: asigna la propiedad al grupo Administradores, lo que puede romper políticas de auditoría si se usa en entornos con control estricto de ownership.
  • Desactivar temporalmente la herencia antes de aplicar icacls evita que una ACL heredada vuelva a negar Delete después de un reinicio.
  • Volúmenes ReFS: el comando icacls funciona, pero los atributos de integridad pueden requerir fsutil integrity set antes de eliminar.
  • Automatización: envolver los pasos en un script PowerShell con Start-Process -Verb RunAs permite programar limpiezas nocturnas sin intervención manual.
  • Registro de auditoría: habilitar Object Access en la política de auditoría ayuda a rastrear qué proceso creó la ACL problemática en primer lugar.

Con este flujo, los archivos rebeldes dejan de ser un obstáculo y el servidor vuelve a mantener su ciclo de ingestión‑procesamiento‑eliminación sin sorpresas.