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

Хм, то есть вот это было просто предположением, гипотезой?:

Понятно, что это всё только игрушка кулцхакеров; в качестве решения резервного копирования оно непригодно, даже если удастся найти волшебные настройки на стороне SFTP или где то ещё, что бы работало.

Я не специалист в юниксах, но мне непонятно, как можно замаунтить устройство (диск) одновременно к нескольким клиентам? Разве монтирование ресурса есть некий "шаринг" этого ресурса?

В виндах такого точно нельзя, значит, нигде нельзя :-)

Возможно, в данном случае сервер выделяет некое место, назовём его "лун", на SFTP, и отдаёт его клиенту.
Клиент его маунтит, и работает с ним, но пока он его держит, никто другой работать с ним не сможет.

Попробуйте размаунтить, и посмотрите, появится ли он на SFTP

Так в виндах тоже есть протокол, SMB.
А "монтирование диска", это, как я понимаю, предоставление некоторого количества блоков, с которыми винда может делать всё, что хочет.

Предоставить одному права read-write, а остальным read-only не получится, т.к. постоянная замена блоков не может отслеживаться синхронно всеми клиентами, ввиду слишком большой нагрузки, и нарушения порядка записи из за кеширования.

Понятно, что бывают специальные ФС, которые всё это умеют, но мы же не знаем, какое "монтирование диска" делается в данном случае?

Не может вообще любой софт в юниксах абсолютно прозрачно подмонтироваться.

Типа, есть сервер SFTP - просто делаем mount
Есть сервер SAP или DNS - просто делаем mount - и они предоставляют полный rerad-write доступ к своим объектам.

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