Тысячи неизвестных учетных записей в разрешениях файлов: как устранить и понять причину

Вы открываете свойства файла .vhdx и видите десятки странных записей вроде S-1-5-83-1-… с полными правами. Паниковать не нужно – это не вирус и не взлом. Такие идентификаторы автоматически создаются Windows для изоляции процессов виртуальных машин. Но почему они остаются, даже если вы давно удалили ВМ? Давайте разбираться.

Откуда берутся «неизвестные» SID в разрешениях

Всё дело в Hyper-V – системе виртуализации, которая лежит в основе WSL2, Docker Desktop и других инструментов. Каждая виртуальная машина (даже временная) получает уникальный SID (Security Identifier) формата

S-1-5-83-1-XXXXX

Это нужно для:

• Изоляции процессов ВМ от основной системы (чтобы скрипты внутри виртуализации не могли повредить ваши личные файлы);
• Разграничения прав между разными ВМ (например, если у вас запущено несколько дистрибутивов WSL2).

Когда вы подключаете виртуальный диск (.vhdx) к ВМ, Windows добавляет соответствующий SID в ACL (список контроля доступа) файла. Проблема в том, что после удаления виртуальной машины её SID не исчезает из разрешений. Со временем таких «мертвых» записей накапливается сотни.

Кстати, аналогичный механизм используется для изоляции UWP-приложений (тех, что из Microsoft Store) – их SID начинаются с

S-1-15-2-...

Но в вашем случае речь именно о Hyper-V.

Как очистить ACL без риска для системы

Самый простой способ – команда

icacls "полный_путь_к_файлу.vhdx" /reset

Она удалит все нестандартные ACE (Access Control Entries), оставив только наследуемые разрешения от родительской папки. Но есть нюансы:

1. Если файл сейчас используется какой-либо виртуальной машиной (например, WSL2), вы потеряете доступ к нему. Проверьте, не запущены ли связанные ВМ в фоне.
2. Команда требует запуска от администратора. Щёлкните правой кнопкой по PowerShell или CMD → «Запустить от имени администратора».

Совет: перед сбросом экспортируйте текущие разрешения командой

icacls файл.vhdx /save output.txt

– так вы сможете восстановить их в случае ошибки.

Если после очистки SID снова появляются – проверьте, не связано ли это с автоматическим созданием временных ВМ. Например, Docker при обновлении образов может генерировать новые машины, а WSL2 пересоздаёт свою ВМ при каждом запуске терминала.

Профилактика: как избежать накопления «мертвых» SID

Полностью отключить механизм изоляции нельзя – это критично для безопасности. Но можно уменьшить «захламление»:

• Удаляйте ненужные .vhdx-файлы. Каждый подключенный диск привязывает свой SID, даже если ВМ уже не существует.
• Используйте отдельные папки для виртуальных дисков. Применяйте icacls /reset к целым директориям раз в месяц, а не к отдельным файлам.
• Для WSL2: экспортируйте дистрибутивы командой wsl –export, а потом импортируйте заново — это создаст новый SID без старых привязок.

Важно: не пытайтесь вручную редактировать SID через «Дополнительные параметры безопасности». Эти идентификаторы динамические, и их «привязка» к конкретным объектам хранится только в системном реестре Hyper-V. Даже если вы впишете туда «красивый» логин, система не сможет его распознать.

Кстати, если видите SID вида

S-1-5-21-...

– это уже реальные пользовательские или системные аккаунты. Их трогать без понимания не стоит
– можно нарушить работу Windows. А записи с 83-м номером в SID безопасны для удаления, если вы уверены, что соответствующие ВМ больше не нужны.