> Cейчас это вызывает определенные сложности, потому что тебе _могут_ принести портативный носитель большого объема, где уже очень желательно иметь какие-то ограничения доступа.

Вы смешиваете 2 никак не связанные задачи. Файловая система NTFS никогда не позиционировалась, как ФС для переносных устройств и это даже не обсуждается. Те, кто форматирует переносные устройства в NTFS, должны быть готовы к её логам, ACL и другим вещам, которые не нужны и даже вредны на переносных устройствах.
Касательно переключения жестких дисков из компа в комп - это вообще административная задача, а не пользовательская.

Если мы говорим о сетевом доступе к данным, когда (не важно по какому протоколу) нужно аутентифицировать и авторизовать, то это другой разговор. Если мы даже забудем о проблемах случайного совпадения идентификаторов, и будем считать что все совпадения умышленные - это получается что там не аутентификация!!!

Аутентификация (в гуманитарном, насколько это возможно, смысле) предполагает олицетворение пользователя. 1. Учетные данные пользователя, предоставляемые для доступа должны быть связаны с человеком-пользователем, который их физически предоставляет.
ИЛИ!
2. Есть некая авторизация на делегирование учетных, когда _пользователь_ разрешил предоставить собственные учетные данные для предъявления третьей стороне.

Не знаю, насколько вы знакомы с Auth(n/z)-темой, предположу что вы разбираетесь в протоколе OAuth2 :)
Первое в терминах OAuth2 - это Authorization Code, либо Implicit flow, а второе On-Behalf-Of flow.

В случае маппинга sid никакой аутентификации не происходит, потому что нет олицетворения, вместо него идет привязка. В терминах OAuth2 это сравнимо с топологией Client Credentials flow. В котором предполагается авторизация сервиса1 (ПК1) на сервисе2 (ПК2). И вот авторизации сервиса 1 на сервисе 2, окромя разрешения админа (Admin Consent), я стесняюсь спросить, на чем основана-то? Как гарантии есть, что замапленный sid пользователя на ПК1, который на самом деле живет на ПК2 будет использоваться именно с ПК2, а не с ПК3?

> И никакой разумной возможности заранее добавить к списку в acl "неместный" sid. (с шарингом в чужом домене тоже трудности)

Я пытаюсь вам объяснить, что это не баг, это фича :)

Отсутствие аутентификации предполагает глубокие доверительные отношения между сервисом 1 и 2, потому что вместо аутентификации сервис 1 просто принимает учетные данные, потому что они пришли от сервиса 2, которому мы автоматически доверяем и пользователь тоже не обязательно знает об этом. Доверительные отношения такого типа должны быть защищены авторизацией. Далее пользователя необходимо авторизовать на ФС и вот только тут мы видим ACL.

> а если у одного из вас уже? И при этом, подчеркиваю, организации вообще никак не связанные.

Давайте сначала устраним противоречие из этого высказывания. Если у вас есть задача на предоставление доступа пользователю из организации 1 к ресурсу внутри организации 2, то по определению это либо связанные организации, либо _еще пока не_ связанные, и их надо связать. Факт предоставления доступа и есть та самая связь в гуманитарном смысле.

В техническом смысле отношения доверия могут быть самыми разными.
- 2 организации с двумя доменами (именно AD тут не принципиален от слова совсем)
Вариант 1: Kerberos Trust
Вариант 2: WS-Trust
Архитектуру траста или федерации, давайте оставим за скобками.

- 1 организация имеет домен, а вторая нет
Вам нужно авторизовать недоменное устройство
Вариант 1: Kerberos (вогнать в домен)
Вариант 2: Привязать локального пользователя к внешнему/доменному и организовать доверие недоменного компьютера по TLS, выписав сертификат для недоменного компьютера, заверенный в организации, имеющей домен. Вот тут вам потребуется AD FS и AD DS с уровнем леса не ниже 2012 R2.
Вариант 3: Есть некий внешний сервер авторизации, которому доверяют оба. Тут уместны эти модные слова облачный, гибридный... И это совсем не обязательно AzureAD, вы сами такой можете настроить на открытых технологиях, благо тут нет никакого вендорлока, все протоколы исторически открытые.

Если в вашей инфраструктуре есть такая вещь как безопасность у вас должна быть некая аутентификация и авторизация сервисов или устройств, а не только пользователей.

> применяется, почему же - традиционным способом, включением его в AD. Ну или для самых отмороженных - через posix acls.

Что касается присоединения к реалму кербероса, хоть в AD - это вполне рабочее решение, хоть в Linux с Kerberos не всё гладко, а что касается POSIX ACLs... ой всё... it's a practical joke :) Равно как и установка корня на NTFS. Вопрос уместности использования духовых язычковых инструментов представителями православного клириканства. Проще говоря, на хрена попу гармонь...
Нету в Linux нормальных ACL и точка.

> zfs у нас (вот жеж блин) неработоспособна без, записывайте: krpc, acl_nfsv4

Наверное, потому что это была нормальная многофункциональная ФС...
> При том что мне там обе они были как телеге мотор от камаза, и лошадь не утягивает, и нахрен бесполезен, и бабу с воза.

А. Вам нужны решения в стиле chmod 777 из 70-х? Вам с таким на Linux.

> В линухе, подозреваю, все еще хуже, потому что у нас нет отдельного acl_nfsv4, и все fs переизобретают свои aclи с нуля, а потом еще и отдельно учатся мапить их в nfs.

О чем я и говорю, несчастные люди.
Была попытка переделать сделав по аналогии с BSD, добавив модуль RichACLs, но task failed successfully.
Причем под улюлюканье баранов, которым "сложна". То ли дело недостандартизированный огрызок POSIX ACL. Им обычно тыкают в нос, типа вот есть у нас ACL на Linux. А на самом деле мрак и безблагодатность.