Сотрудник уходит, его учётную запись блокируют, потом удаляют. Допустим, до этого он успел раздать клиенту и подрядчику пару ссылок на файлы с Яндекс Диска.
Какие из этих ссылок перестанут открываться? Какие будут работать и дальше, и чьё место на Диске будет занимать файл?
Справка Яндекс 360 прямо на это не отвечает. Я проверил сам, на двух тестовых учётных записях своей организации. В моём опыте две ссылки разошлись по одному признаку: на чьём Диске лежал файл. Ссылка на файл, который ушедший положил в папку коллеги, пережила и блокировку, и удаление. Ссылка на файл с его собственного Диска умерла уже на блокировке.
Перед блокировкой вы сможете собрать ссылки сотрудника, отделить файлы с его личного Диска, перенести нужные к коллеге и раздать ссылки заново. После блокировки - проверить каждую старую ссылку одним GET-запросом без токена.
Ссылка, которую раздал ушедший (мой опыт, доступ “Редактирование”) |
После блокировки |
После удаления |
|---|---|---|
на файл в папке коллеги |
открывается |
открывается, API отвечает 200 |
на файл со своего Диска |
“У вас нет доступа или такой страницы нет” |
API отвечает 404 |
Проверить ссылку можно без браузера
У REST API Диска есть метод для публичных ресурсов (документация метода). Ссылка идёт в параметре public_key, а OAuth-токен, как сказано в документации, “в таких запросах указывать не нужно”.
Ответ по ссылке на архив в папке коллеги, поля выписаны не все. Ключи обеих ссылок здесь заменены заглушкой:
GET https://cloud-api.yandex.net/v1/disk/public/resources?public_key=https://disk.360.yandex.ru/d/<ключ> HTTP 200 "name": "test-392mb.zip" "size": 411897894 "created": "2026-09-23T09:58:01+00:00" "modified": "2026-09-23T11:17:23+00:00" "views_count": 7
А это ссылка на файл, который лежал на Диске самого ушедшего:
GET https://cloud-api.yandex.net/v1/disk/public/resources?public_key=https://disk.360.yandex.ru/i/<ключ> HTTP 404 "error": "DiskNotFoundError" "description": "Resource not found." "message": "Не удалось найти запрошенный ресурс."
Оба ответа сняты 23 сентября 2026 года в 15:45 по Москве. Учётную запись ушедшего я удалил в 14:08. Первый прогон, в 15:06, вернул те же имя и размер архива и тот же DiskNotFoundError.
Время в created и modified - по UTC. 09:58 - это 12:58 по Москве, время создания архива в папке. В 14:17 хозяин папки отправил архив в свою корзину и через 22 секунды восстановил, отсюда 11:17 в modified. Ссылку это не сломало: через полтора часа она отдала 200.
Где лежит файл, по такому ответу не понять. Поля с владельцем нет ни в этом ответе, ни в таблице объекта Resource в описании ответов API, а path у опубликованного файла, по той же таблице, всегда равен /. Для этой задачи метод годится на одно: проверить, жива ли ссылка.
Список старых ссылок проверяется простым циклом. 200 с именем файла - ссылка жива, у мёртвой в моём опыте был 404 с DiskNotFoundError. Отказ ещё не приговор. В начале раздела документации метода стоит врезка: “Метаинформация о запрошенном ресурсе недоступна, если владелец ссылки на файл или папку установил запрет на скачивание”. Какой код придёт в этом случае, страница не называет.
Как был устроен опыт
Обе учётные записи - назову их А и Б - я завёл на домене организации. Приглашённого по ссылке заблокировать бы не вышло: по странице справки “Сотрудники”, такие аккаунты “нельзя редактировать и блокировать”. Тариф один, день один - 23 сентября 2026 года, время ниже московское.
А создал папку “Тест общая” и выдал Б персональный доступ “Редактирование”. Доступ по ссылке у папки тоже был включён, с тем же уровнем.
Б загрузил в папку А архив test-392mb.zip на 392,8 МБ.
Б создал две публичные ссылки: на этот архив и на файл со своего Диска. Файлом оказался скриншот, который Б раньше сохранил себе.
Обе ссылки открылись и скачались в окне инкогнито, под личным Яндексом вне домена.
Б я заблокировал, а через 40 минут, в 14:08, удалил.
Ссылку на чужой архив создавал сам Б, из своего окна. Хозяин папки её не выдавал.
Место списалось с хозяина папки
До загрузки у обоих стояло “Занято 0 байт из 1 ТБ”. Архив положил Б, а счётчик вырос у А.
Счётчик Диска А после того, как Б загрузил архив в папку А.
Счётчик Диска Б после той же загрузки.
3,17 КБ у Б - это тот самый скриншот, на который вела вторая ссылка. Архив в них не входит.
Со справкой это сходится. Страница Со мной поделились ссылкой говорит: “Любой файл, добавленный в чужую папку, будет занимать место на Диске владельца этой папки”.
Б загрузил второй экземпляр архива на общий диск организации. Личные счётчики обоих после этого не сдвинулись: 392 МБ у А, 3,17 КБ у Б.
Блокировка: одна ссылка умерла ещё до удаления
После блокировки А открыл свою папку. Архив, который загрузил Б, был на месте и скачивался. В свойствах файла у А стояло “Владелец: Я”.
Снаружи ссылки повели себя по-разному.
Слева - ссылка на файл с Диска Б, справа - на архив в папке А. Снимок сделан после блокировки Б, до удаления.
Сам Б при входе видел “Аккаунт заблокирован”.
Про блокировку страница Сотрудники пишет: “Заблокированный сотрудник не сможет пользоваться Почтой и другими сервисами, подключенными к организации, но вся информация о его аккаунте сохранится”. Дальше раздел о блокировке расписывает Почту. Диск этот раздел не упоминает.
Информация об аккаунте заблокированного, по справке, сохраняется. А ссылка на файл с его Диска в моём опыте перестала открываться ещё до удаления. Когда именно внутри этих 40 минут, я не засёк.
Что осталось у хозяина папки после удаления
Свойства архива в окне А, снято после удаления Б. Время на снимке - по поясу учётной записи, это Москва плюс два часа.
Счётчик у А после удаления остался на 392 МБ. Ссылка на архив открывалась, ссылка на файл с Диска Б - нет. Архив на общем диске тоже остался на месте. Корзина организации показывала “В корзине пусто”.
Про удаление доменного аккаунта на странице “Сотрудники” стоит врезка: “Если вы удалите аккаунт, созданный на вашем домене, сотрудник потеряет все данные на Яндекс Диске и в Яндекс Почте. Восстановить данные будет невозможно”. Что станет с файлами, которые он раздал коллегам, раздел об удалении не описывает. В моём опыте архив к данным Б уже не относился: владельцем в свойствах стоял А.
Что я бы сделал до блокировки
Это мои выводы из одного опыта, не правило платформы.
Собрать ссылки, которые уходящий раздавал наружу: спросить его самого и тех, с кем он работал.
У него же выяснить, где лежит каждый файл: на его Диске или в чужой папке.
Нужное с его Диска до блокировки перенести в папку того, кто остаётся. В частых вопросах страницы “Со мной поделились ссылкой” такой случай назван прямо: “Я перемещаю свой файл в чужую папку, и владельцем файла становится другой человек”. Для файла с персональным доступом там же предупреждение: “Старая ссылка на файл может не работать”. Ссылку я бы выдал заново.
Про ссылки на файлы в чужих папках отдельно решить, нужны ли они после ухода сотрудника. У меня такая ссылка пережила удаление, и архив по ней открывался снаружи. Закроет ли её хозяин папки из своего окна, я не проверял.
После блокировки прогнать каждую старую ссылку через
public/resourcesи тем, чья ссылка умерла, отправить новую. Отказ по ссылке с запретом на скачивание смертью не считать: по документации метода, метаинформация у такой ссылки недоступна и тогда, когда она жива.
Где этот опыт может ошибаться
Самый сильный довод против - масштаб. Один тариф, две учётные записи, доступ “Редактирование” у Б и включённый у папки А доступ по ссылке с тем же уровнем. Ссылку на чужой архив создавал Б, а не хозяин папки. При доступе “Просмотр”, при выключенном доступе по ссылке к папке, при других настройках администратора или со ссылкой от самого А результат может быть другим: эти случаи я не проверял и переносить на них итог не стану. Справка Яндекс 360 о ссылках ушедшего сотрудника молчит, так что до повторного опыта я знаю ровно две строки таблицы в начале.