Как смонтировать S3-совместимое объектное хранилище в Linux через rclone

Для монтирования S3-совместимого Object Storage в Linux через rclone нужно установить rclone и FUSE, создать отдельный S3 remote с endpoint и credentials, проверить доступ к bucket и затем подключить его через rclone mount.

Для более стабильной записи стоит использовать VFS cache, например с --vfs-cache-mode writes, а постоянный mount лучше запускать через systemd, а не вручную или только через --daemon.

Важно помнить, что S3 mount лишь эмулирует файловую систему. Он подходит для архивов, медиа и других относительно редко изменяемых данных, но хуже справляется с базами данных, частыми случайными записями и приложениями, которым нужна строгая POSIX-семантика.

Если постоянный файловый доступ не нужен, для backup и периодической передачи данных обычно проще и надежнее использовать rclone sync или rclone copy.

Зачем монтировать Object Storage как файловую систему 

Добро пожаловать!

S3-совместимое Object Storage удобно использовать для резервных копий, архивов, медиафайлов и больших наборов данных. Но иногда приложению или администратору недостаточно работать с ним через отдельные команды вроде upload, download или sync.

Хочется открыть обычный каталог Linux, зайти в него через cd, посмотреть содержимое через ls и работать с удаленными объектами почти как с файлами на локальном диске.

Именно для этого можно использовать rclone mount. Это не является стабильным решением (так как работает через FUSE), и противоречит концепции объектного хранилища, но для некоторых легаси-систем и переходных периодов может быть удачным подходом.

В этой статье разберем, как установить rclone, подключить S3-совместимое хранилище через собственный endpoint, проверить соединение и вручную смонтировать bucket через FUSE. Затем настроим VFS cache, права доступа и автоматический запуск через systemd.

Отдельно поговорим о том, где заканчивается удобство такого подхода.

Потому что S3 mount выглядит как обычная файловая система, но внутри по-прежнему остается объектным хранилищем. Это влияет на производительность, операции переименования, запись файлов, блокировки и сценарии использования.

В конце разберемся, когда постоянное монтирование действительно удобно, а когда лучше вообще отказаться от mount и использовать обычный rclone sync.

Как rclone превращает Object Storage в «диск» Linux

Если подключить S3 bucket через rclone, в системе может появиться обычная точка монтирования, например /mnt/storage.

После этого можно выполнить ls /mnt/storage, открыть файл через приложение или скопировать туда данные привычными Linux-инструментами.

Но физического диска за этим каталогом нет.

Между Linux и S3 находится дополнительный слой, который переводит файловые операции в запросы к Object Storage.

Чтобы дальше правильно воспринимать поведение rclone mount, сначала разберем, как именно устроен этот слой.

Почему S3 нельзя смонтировать как обычную файловую систему

Обычная файловая система вроде ext4 или XFS работает с блочным устройством.

У нее есть привычные сущности:

• файлы;
• каталоги;
• inode;
• права доступа;
• временные метки;
• операции чтения и записи отдельных блоков;
• переименование;
• файловые блокировки.

S3 устроен иначе.

В нем нет диска, который Linux может просто подключить через mount. Вместо этого есть HTTP API, через который клиент создает, читает и удаляет объекты.

То есть классическая схема выглядит примерно так:

А для S3:

Поэтому команда стандартного монтирования вроде mount /dev/sdb1 /mnt/data здесь неприменима: никакого /dev/sdb1 у Object Storage просто нет.

Чтобы показать S3 как каталог Linux, нужен посредник, который будет получать файловые операции от ядра и преобразовывать их в запросы к удаленному API.

Эту роль и выполняет связка rclone + FUSE.

Что делает FUSE

FUSE расшифровывается как Filesystem in Userspace.

Это механизм Linux, который позволяет реализовать файловую систему не внутри ядра, а обычной программой в пользовательском пространстве.

С точки зрения системы всё выглядит так, будто по адресу /mnt/storage находится файловая система.

Но когда приложение выполняет, например, чтение файла, запрос передается не локальному диску, а процессу, в нашем случае в роли такого процесса будет выступать rclone.

Дальше rclone уже решает, какие действия нужно выполнить через S3 API.

Упрощенно цепочка выглядит так:

То же самое происходит в обратную сторону.

Если приложение создает файл в точке монтирования, rclone должен преобразовать эту операцию в загрузку объекта в S3.

Именно FUSE позволяет сделать этот переход прозрачным для большинства обычных программ.

Приложению не обязательно знать, что файл физически находится в Object Storage. Оно просто работает с путем вроде /mnt/storage/report.pdf.

Как rclone преобразует object key в привычные пути

Как и в предыдущей статье про AWS CLI, важно помнить: в S3 нет настоящего дерева каталогов.

Допустим, в bucket существуют объекты с ключами:

documents/report.pdf

documents/contracts/2026.pdf

images/logo.png

Для S3 это просто три ключа.

Но rclone может представить их Linux как:

То есть символ / внутри object key интерпретируется как разделитель каталогов.

Благодаря этому команда ls показывает привычную структуру, хотя физически отдельные директории documents и contracts могут вообще не существовать как самостоятельные объекты.

Это особенно хорошо видно на пустых каталогах.

В обычной файловой системе можно создать директорию и ничего в нее не класть.

В S3 пустая папка сама по себе обычно не имеет смысла. Некоторые клиенты создают специальный нулевой объект-маркер, чтобы визуально сохранить каталог, но это уже условность клиентского интерфейса.

Поэтому дерево, которое показывает rclone, лучше воспринимать как представление object key в форме файловой системы, а не как реальную внутреннюю структуру S3.

Почему такое монтирование остается эмуляцией файловой системы

Это ключевая мысль всей нашей работы.

После rclone mount каталог действительно ведет себя во многом как обычная файловая система, но S3 от этого не превращается в ext4.

rclone просто старается адаптировать две разные модели друг к другу.

И некоторые операции ему приходится эмулировать.

Например, в обычной файловой системе переименование файла внутри одного раздела может быть очень дешевой операцией: меняются метаданные, а сами данные остаются на месте.

В S3 имя фактически является частью object key.

Поэтому изменение пути с old/report.pdf на new/report.pdf может потребовать создать объект под новым ключом и удалить старый.

Для большого объекта это уже совсем другая стоимость и задержка.

Похожая проблема появляется при приложениях, которые постоянно открывают файл, меняют отдельные участки и сохраняют его обратно.

Обычный локальный диск хорошо подходит для случайной записи небольшими блоками.

Object Storage обычно рассчитано на работу с целыми объектами.

Чтобы скрыть часть этих различий, rclone использует VFS-слой и локальный кэш, который мы подробно настроим дальше.

Но полностью убрать фундаментальные особенности S3 невозможно.

Поэтому rclone mount лучше воспринимать как удобный файловый интерфейс поверх объектного хранилища.

Для просмотра документов, медиа, архивов и относительно последовательной работы с файлами такой подход может быть очень удобным.

А вот для базы данных, интенсивной случайной записи или приложений, которые рассчитывают на строгую POSIX-семантику, уже может потребоваться настоящая файловая система.

Теперь, когда понятна сама архитектура S3 mount и роль FUSE, стоит коротко посмотреть на альтернативу. rclone — не единственный инструмент, который умеет показывать S3 bucket как каталог Linux, поэтому перед практической настройкой сравним его с s3fs и разберемся, чем отличаются эти подходы.

Чем rclone mount отличается от s3fs

rclone mount — не единственный способ представить S3 bucket как каталог Linux. Еще один распространенный вариант — s3fs, который также работает через FUSE и преобразует файловые операции в запросы к S3 API.

У инструментов немного разный акцент. s3fs изначально создавался именно как файловый интерфейс поверх S3 и поддерживает значительную часть привычных POSIX-атрибутов и операций: права доступа, uid/gid, символические ссылки и extended attributes. Но ограничения объектного хранилища никуда не исчезают: например, S3 по-прежнему не дает обычных атомарных переименований, hard links или полноценной координации нескольких клиентов.

rclone mount, в свою очередь, делает большой упор на VFS-слой. Через --vfs-cache-mode можно выбирать, насколько активно использовать локальный кэш: от почти прямой работы с remote до кэширования чтения и записи. За счет этого rclone можно гибко адаптировать под приложения, которым нужен более привычный файловый интерфейс, но за повышенную совместимость приходится платить локальным диском и дополнительными ресурсами.

Поэтому нельзя универсально сказать, что один инструмент всегда «легче» или быстрее другого. Выбор зависит от нагрузки, требований приложения к файловым операциям и настроек кэширования. s3fs имеет смысл рассматривать как более специализированную альтернативу для S3 mount, а rclone — как более универсальный инструмент, который, кроме mount, умеет copy, sync и работать с множеством других backend.

В этом руководстве дальше будем использовать именно rclone mount. Он дает гибкую работу через VFS cache, хорошо подходит для S3-compatible хранилищ и позволяет тем же инструментом выполнять copy, sync и другие операции. Теперь можно переходить к практике: установим rclone, проверим FUSE и подготовим Linux к первому подключению S3-compatible хранилища. 

Устанавливаем rclone и проверяем FUSE

Какие компоненты понадобятся

Для базовой схемы нужны три вещи:

• Linux-система;
• rclone;
• FUSE.

rclone отвечает за подключение к S3 API и преобразование операций с файлами в запросы к объектному хранилищу.

FUSE нужен уже для другой части задачи — чтобы представить remote как обычный каталог Linux.

То есть их роли разные: rclone понимает, как работать с S3, а FUSE позволяет встроить это взаимодействие в файловое дерево системы.

На современных дистрибутивах Linux поддержка FUSE обычно уже доступна. Но сам пользовательский пакет может потребоваться установить отдельно.

Например, в Ubuntu чаще всего используется пакет fuse3.

Чем пакет из репозитория отличается от официальной установки rclone

Самый простой способ установить rclone — взять пакет из репозитория дистрибутива.

В Ubuntu это можно сделать через APT.

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

Но есть и нюанс.

Версия rclone в репозитории конкретного выпуска Ubuntu может быть старее актуального релиза проекта.

Это не всегда проблема. Для базовых операций вроде copy, sync и mount даже не самая новая версия обычно подходит нормально.

Но если нужны свежие параметры VFS, исправления для конкретного backend или новые возможности S3, версия начинает иметь значение.

Поэтому есть два основных подхода:

1. Установить rclone из репозитория системы.
2. Использовать официальный установочный скрипт rclone.

Для обычного серверного гайда первый вариант удобнее как базовый, потому что он проще и предсказуемее.

А официальный способ имеет смысл, если требуется более свежая версия.

При этом перед использованием установочного скрипта в production разумно сначала ознакомиться с его содержимым и официальной документацией проекта, а не бездумно отправлять удаленный скрипт напрямую в shell.

Как проверить версию rclone и наличие FUSE

После установки сначала проверим, что rclone вообще запускается.

Для этого используется команда rclone version.

В выводе будут указаны версия клиента, операционная система и архитектура.

Это полезно не только для проверки установки. Если позже возникнет проблема с определенным параметром, версия rclone сразу покажет, поддерживается ли он вообще.

Теперь нужно проверить FUSE.

Самый простой вариант — убедиться, что установлен соответствующий пакет и доступна утилита fusermount3.

Например, команда fusermount3 --version показывает версию пользовательского компонента FUSE 3.

Дополнительно можно проверить наличие устройства /dev/fuse. Если оно существует, ядро предоставляет FUSE-интерфейс приложениям пользовательского пространства.

На обычном VPS это чаще всего уже настроено.

Но внутри некоторых контейнеров ситуация может быть другой: /dev/fuse может отсутствовать, а использование FUSE — быть запрещено политикой контейнера. В таком окружении rclone mount не заработает просто установкой пакета.

Это важное отличие: команда rclone copy или rclone sync может нормально работать внутри контейнера, а rclone mount — нет, потому что именно монтирование требует доступа к FUSE.

Практика

Для Ubuntu можно установить rclone и FUSE 3 так:

sudo apt update

sudo apt install -y rclone fuse3

После этого проверим rclone: rclone version

Проверим FUSE: fusermount3 --version

И наличие устройства: ls -l /dev/fuse

Если rclone установлен, fusermount3 доступен, а /dev/fuse существует, система готова к дальнейшей настройке.

Мини-таблица команд

Теперь Linux готов к монтированию, но rclone пока еще не знает, к какому S3-хранилищу обращаться.

Следующим шагом создадим отдельный remote, укажем собственный endpoint провайдера и сохраним credentials в конфигурации rclone.

Добавляем S3-совместимое хранилище в rclone

Что такое remote в rclone

Remote можно представить как профиль подключения.

Он объединяет несколько настроек в одно короткое имя.

Например, вместо того чтобы каждый раз указывать endpoint, Access Key, Secret Key и регион, достаточно один раз создать: storage

После этого команды становятся намного короче.

Например, просмотр bucket может выглядеть так:

rclone lsd storage:

А работа с конкретным bucket:

rclone ls storage:my-bucket

То есть remote отвечает на вопрос: Как подключаться к этому хранилищу?

А уже часть после двоеточия определяет, с каким bucket или путем внутри него работать.

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

Какие параметры нужно получить у провайдера

Для S3-compatible remote обычно понадобятся те же основные данные, что и при работе через AWS CLI:

• Access Key ID;
• Secret Access Key;
• endpoint;
• регион;
• иногда дополнительные параметры, зависящие от конкретного сервиса.

Endpoint может выглядеть, например, так: https://s3.example-provider.com

А регион — так: us-east-1

Или вообще иметь собственное имя провайдера.

Кроме того, rclone во время настройки предложит выбрать S3 provider.

В списке есть Amazon, Ceph, MinIO и другие варианты, но для стороннего S3-совместимого сервиса обычно используется пункт вроде Other.

Это важно, потому что provider влияет на некоторые значения по умолчанию и особенности работы backend.

Если провайдер прямо указывает в документации, какой вариант выбирать в rclone, лучше следовать именно его инструкции.

Как выбрать тип S3 и указать собственный endpoint

Настройка выполняется через интерактивную команду rclone config.

После запуска rclone покажет меню управления remote.

Для нового подключения выбираем создание нового remote, задаем ему имя, например storage, а затем выбираем тип хранилища s3.

Дальше rclone последовательно запросит параметры подключения.

Логика примерно такая:

1. Создать новый remote.
2. Задать имя storage.
3. Выбрать тип s3.
4. Выбрать подходящего provider, для универсального S3-compatible варианта — Other.
5. Указать Access Key ID.
6. Указать Secret Access Key.
7. Задать регион.
8. Указать собственный endpoint.
9. Остальные параметры оставить по умолчанию, если документация провайдера не требует другого.

Главное здесь — не пытаться угадывать значения.

Если endpoint или region указаны неправильно, remote сохранится, но последующие запросы могут завершаться ошибками соединения или подписи.

Поэтому перед настройкой лучше заранее открыть панель или документацию провайдера и подготовить все параметры.

Где rclone хранит конфигурацию и credentials

rclone сохраняет настройки remote в собственном конфигурационном файле.

Точный путь можно узнать командой rclone config file.

На Linux это обычно файл внутри пользовательского каталога конфигурации, например:

~/.config/rclone/rclone.conf

В нем может находиться примерно такая секция:

    
        
    [storage]
type = s3
provider = Other
access_key_id = ACCESS_KEY
secret_access_key = SECRET_KEY
endpoint = https://s3.example-provider.com

Конкретный набор строк зависит от версии rclone и выбранных параметров.

Важно понимать, что этот файл содержит чувствительную информацию.

rclone может скрывать или обфусцировать часть значений в некоторых сценариях, но конфигурационный файл всё равно нужно считать секретным.

Его не стоит:

• Публиковать где либо;
• Добавлять в Git;
• Прикладывать целиком к тикетам;
• Копировать в общедоступные каталоги.

Проверить, какой конфигурационный файл сейчас использует rclone, безопаснее через rclone config file, а не через вывод его содержимого.

Почему лучше создать отдельный remote для каждого хранилища

Технически можно постоянно редактировать один remote и менять в нем endpoint или credentials.

Но почти сразу это становится неудобно.

Допустим, один сервер работает с двумя хранилищами:

backup-storage

media-storage

У них разные endpoint, ключи и регионы.

Если хранить их как два отдельных remote, команды остаются понятными: backup-storage:backups и media-storage:images

Это снижает риск случайно отправить данные не тому провайдеру или использовать неправильные credentials.

Практика: создаем S3-compatible remote

Запускаем конфигуратор: rclone config

Дальше выбираем создание нового remote: n) New remote

Задаем имя: storage

Для типа хранилища выбираем S3: s3

Если это сторонний S3-compatible сервис и документация не требует другого варианта, выбираем provider Other.

После этого вводим Access Key, Secret Key, region и endpoint, полученные у провайдера.

Дополнительные параметры можно оставить по умолчанию, если сервис не требует отдельной настройки addressing style, ACL или других опций.

После сохранения проверим, что remote появился: rclone listremotes

В выводе должно появиться: storage:

Посмотреть путь к конфигурационному файлу можно так: rclone config file

Команды из главы

Remote готов, но само наличие конфигурации еще не доказывает, что endpoint и credentials действительно работают.

Поэтому следующим шагом сначала выполним безопасные команды чтения и проверим соединение до того, как переходить к монтированию через FUSE.

Проверяем соединение до монтирования

Почему сначала лучше использовать команды чтения

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

Например, rclone lsd и rclone ls.

Они позволяют проверить сразу несколько вещей:

• endpoint доступен;
• credentials подходят;
• регион не конфликтует с запросами;
• remote действительно используется;
• у пользователя есть хотя бы базовые права чтения.

Если такая команда завершается успешно, можно уже переходить к FUSE.

А если она падает, проблему проще искать именно в конфигурации подключения, а не в параметрах mount.

Как посмотреть buckets и содержимое bucket

Чтобы посмотреть bucket, доступные через remote storage, можно использовать:

rclone lsd storage:

Если у учетной записи есть право на просмотр списка bucket, rclone покажет их примерно так:

    
        
    -1 2026-09-16 12:00:00        -1 backups
-1 2026-09-16 12:01:00        -1 media

Если список пустой, это не обязательно ошибка. Возможно, bucket еще не созданы.

Теперь можно посмотреть содержимое конкретного bucket:

rclone ls storage:my-bucket

Команда выводит объекты и их размеры.

Например:

    
        
    128 test.txt
54213 documents/report.pdf
2489143 backups/archive.tar.gz

Если файлов много, полезнее может оказаться rclone lsd storage:my-bucket, который показывает только каталоги и префиксы верхнего уровня.

Есть и еще одна полезная команда:

rclone about storage:

Она запрашивает информацию об объеме хранилища, если backend и провайдер поддерживают такую операцию.

Для S3-compatible сервисов about может быть недоступен или возвращать ограниченную информацию, поэтому отсутствие результата здесь само по себе не означает проблему.

Чем ошибка соединения отличается от ошибки credentials

Если rclone не может подключиться к endpoint вообще, ошибка обычно связана с сетью или адресом сервиса.

Причины могут быть такими:

• неправильный endpoint;
• DNS не разрешается;
• сервис недоступен;
• firewall блокирует соединение;
• TLS-соединение завершается ошибкой.

В этом случае проблема возникает еще до нормальной проверки credentials.

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

Например, причиной может быть неверный Access Key, Secret Key или неподходящий регион.

Также возможна ситуация, когда credentials правильные, но права ограничены. Тогда один запрос может работать, а другой завершаться AccessDenied.

Например, пользователь может иметь доступ к storage:my-bucket, но не иметь права получать список всех bucket через storage:.

Поэтому при диагностике лучше проверять не только корень remote, но и конкретный bucket, к которому должен быть доступ.

Мини-таблица команд

Если rclone успешно читает содержимое bucket, значит базовое подключение работает. Теперь уже можно добавлять следующий слой — FUSE — и представить этот bucket как обычный каталог Linux.

Монтируем bucket вручную через FUSE

На этом этапе remote уже проверен, поэтому можно перейти к самому rclone mount.

Ручное монтирование полезно сделать первым хотя бы один раз. Так проще проверить точку монтирования, права и поведение файловой системы до того, как переносить запуск в systemd.

Создаем точку монтирования

Сначала нужен обычный локальный каталог.

Например: /mnt/storage

Создадим его: sudo mkdir -p /mnt/storage

Но здесь сразу возникает вопрос прав.

Если rclone будет запускаться от обычного пользователя, а каталог принадлежит root, процесс может не получить нужные возможности.

Поэтому точку монтирования лучше передать тому пользователю, от которого будет работать rclone: sudo chown $USER:$USER /mnt/storage

После этого каталог готов.

Сам по себе он пока пустой и ничем не отличается от обычной директории.

Как работает rclone mount

Базовая команда выглядит так: rclone mount storage:my-bucket /mnt/storage

Первая часть определяет источник: storage:my-bucket

Вторая — локальную точку монтирования: /mnt/storage

После запуска rclone подключается к remote и через FUSE создает виртуальную файловую систему.

Теперь объект: documents/report.pdf, будет доступен как: /mnt/storage/documents/report.pdf

И с ним можно работать обычными Linux-командами: ls /mnt/storage или cat /mnt/storage/test.txt

Для приложения это выглядит как обычный файловый путь.

Но фактически данные продолжают находиться в Object Storage, а rclone переводит операции чтения и записи в запросы к S3 API.

Почему процесс должен оставаться запущенным

Есть важная особенность: rclone mount — это не одноразовая команда.

Пока точка монтирования существует, должен работать процесс rclone, который обслуживает FUSE-запросы.

Если запустить:

rclone mount storage:my-bucket /mnt/storage

в обычном терминале, команда останется в foreground.

Это нормально.

Если закрыть терминал или завершить процесс rclone, mount исчезнет или станет недоступен.

Для теста это даже удобно: видно, что процесс работает прямо сейчас.

Для постоянного использования позже перенесем запуск в systemd, который будет:

• Запускать mount автоматически;
• Перезапускать rclone после сбоя;
• Сохранять логи;
• Поднимать mount после перезагрузки сервера.

Параметр --daemon тоже позволяет отправить rclone в фон, но для production systemd обычно удобнее и надежнее.

Как проверить, что mount появился в системе

Пока rclone mount работает, откроем второй SSH-сеанс или терминал.

Сначала посмотрим содержимое: ls -la /mnt/storage

Если в bucket есть объекты, они должны появиться здесь как файлы и каталоги.

Проверить сам факт монтирования можно через: mount | grep /mnt/storage или findmnt /mnt/storage

Последний вариант обычно удобнее, потому что показывает источник, точку монтирования и тип файловой системы в компактном виде.

Можно также попробовать прочитать существующий файл: cat /mnt/storage/test.txt

Если содержимое выводится корректно, цепочка уже работает полностью:

    
        
    Linux
→ FUSE
→ rclone
→ S3 API
→ bucket

Когда ручная проверка закончена, mount можно остановить через Ctrl+C в терминале, где запущен rclone.

Либо размонтировать его отдельно: fusermount3 -u /mnt/storage

Мини-таблица команд

На этом этапе bucket уже выглядит как обычный каталог Linux. Но пока rclone в основном просто переводит файловые операции в S3-запросы, а некоторые приложения ожидают гораздо более привычного поведения локального диска.

Чтобы сгладить это различие, дальше настроим VFS cache — один из самых важных компонентов стабильной работы rclone mount.

Настраиваем VFS cache

Зачем rclone нужен VFS-слой

VFS расшифровывается как Virtual File System.

В контексте rclone это дополнительный слой между приложением и удаленным хранилищем, который помогает сделать поведение mount более похожим на обычную файловую систему.

Упрощенно схема становится такой:

Вместо того чтобы каждое маленькое изменение немедленно отправлять в S3, rclone может временно работать с локальной копией файла, а затем синхронизировать результат с Object Storage.

Это особенно полезно для программ, которые ожидают возможность:

• Повторно открывать файл;
• Менять его частями;
• Выполнять seek;
• Записывать данные не строго последовательно;
• Работать с временными файлами.

То есть VFS cache не меняет природу S3, но помогает сгладить различия между объектным хранилищем и обычной файловой системой.

Что меняет --vfs-cache-mode

Главный параметр здесь — --vfs-cache-mode.

Он определяет, насколько активно rclone должен использовать локальный диск как промежуточный кэш.

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

То есть всегда приходится искать баланс между:

• Совместимостью;
• Производительностью;
• Расходом локального диска;
• Скоростью передачи данных в S3.

Для простого чтения может быть достаточно минимального режима.

Для приложений, которые активно записывают файлы, обычно нужен более полноценный cache.

Чем отличаются off, minimal, writes и full

У rclone есть несколько основных режимов VFS cache. Для удобства составил таблицу для вас:

Для типичного server-side mount часто хорошей отправной точкой становится: --vfs-cache-mode writes

Он позволяет нормально обрабатывать запись файлов, не превращая локальный диск в полный кэш всего читаемого содержимого.

full полезен, если приложения постоянно читают одни и те же данные или активно выполняют seek внутри больших файлов.

Но такой режим требует уже намного внимательнее следить за размером cache.

Где хранится локальный кэш

По умолчанию rclone использует собственный каталог cache внутри пользовательского окружения.

Точный путь можно посмотреть через: rclone config paths

Но для серверной конфигурации часто удобнее указать каталог явно.

Например: /var/cache/rclone или /home/rclone/.cache/rclone

Это дает несколько преимуществ.

Сразу понятно:

• Где лежит кэш;
• На каком разделе он находится;
• Сколько места ему доступно;
• Какие права нужны systemd-сервису.

Указать каталог можно параметром --cache-dir.

Например: --cache-dir /var/cache/rclone

При этом каталог должен быть доступен пользователю, от которого работает rclone.

Как ограничить размер и срок хранения кэша

Если VFS cache оставить без контроля, он может занять заметную часть локального диска.

Поэтому для production лучше сразу настроить ограничения.

Параметр --vfs-cache-max-size задает максимальный размер кэша.

Например: --vfs-cache-max-size 10G

А --vfs-cache-max-age ограничивает срок хранения неиспользуемых данных.

Например: --vfs-cache-max-age 24h

То есть старые кэшированные данные постепенно очищаются.

Это особенно важно на небольших VPS.

Если системный диск имеет всего 20–40 ГБ свободного места, бесконтрольный VFS cache может однажды заполнить раздел и вызвать уже совсем другие проблемы: от ошибок записи до сбоев сервисов.

Нужно учитывать и еще один нюанс: ограничение размера не всегда означает, что rclone мгновенно остановится ровно на указанной границе.

Очистка происходит периодически, а открытые или активно используемые файлы могут продолжать занимать место.

Поэтому между --vfs-cache-max-size и реальным свободным пространством лучше оставлять запас.

Почему кэш расходует локальный диск

Иногда возникает логичный вопрос: Если данные находятся в Object Storage, зачем вообще нужен большой локальный диск?

Потому что VFS cache фактически использует его как промежуточное рабочее пространство.

Например, приложение записывает файл размером 8 ГБ.

При --vfs-cache-mode writes rclone может сначала сохранить значительную часть этого файла локально, а затем отправить его в S3.

То есть mount не избавляет сервер от локального диска полностью.

Он просто переносит постоянное хранение данных в Object Storage, а локальный диск используется для кэша, временных данных и операций, которые нельзя удобно выполнить напрямую через S3 API.

Это особенно важно учитывать при больших файлах.

Если ожидается работа с объектами по 50–100 ГБ, а на VPS свободно 10 ГБ, режим full или активная запись через cache может быстро упереться в ограничение диска.

Практика: включаем VFS cache

Создадим отдельный каталог:

sudo mkdir -p /var/cache/rclone

sudo chown $USER:$USER /var/cache/rclone

Теперь запустим mount с режимом writes:

    
        
    rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone

Добавим ограничение размера:

    
        
    rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone \
--vfs-cache-max-size 10G

И ограничение возраста:

    
        
    rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone \
--vfs-cache-max-size 10G \
--vfs-cache-max-age 24h

В следующем блоке расскажу про основные параметры и то, что они делают. 

Основные параметры VFS cache

Теперь mount уже лучше приспособлен к приложениям, которые работают с файлами не только на чтение.

Но остается еще один важный слой — права доступа. Потому что пользователь Linux, который видит /mnt/storage, и S3 service account, который имеет доступ к объектам, — это две разные системы авторизации.

Разбираемся с правами доступа

Когда bucket смонтирован, в работе одновременно участвуют сразу два уровня прав:

1. Локальные права Linux и FUSE;
2. Permissions самого S3-хранилища.

Они связаны только косвенно.

Можно настроить /mnt/storage так, чтобы каталог был виден всем пользователям Linux, но при этом rclone все равно не сможет удалить объект, если его S3 credentials не имеют DeleteObject.

И наоборот, service account может иметь полный доступ к bucket, но другой Linux-пользователь не сможет открыть точку монтирования из-за ограничений FUSE.

От какого Linux-пользователя работает mount

По умолчанию rclone mount работает от того пользователя, который запустил процесс.

Например, если команду выполняет пользователь ubuntu, именно он становится основным владельцем FUSE mount.

Это влияет на доступ к:

• Точке монтирования;
• VFS cache;
• Конфигурации rclone;
• Файлам и каталогам внутри mount.

Поэтому для systemd позже будет особенно важно явно указать пользователя через User=.

Запускать rclone от root без необходимости обычно не стоит. Лучше выделить обычного пользователя с минимальными правами и дать ему доступ только к нужным каталогам.

Что меняют --uid, --gid и --umask

Так как реальные POSIX-права объектов в S3 отсутствуют, rclone должен эмулировать владельца и режим доступа для файлов, которые показывает Linux.

Для этого используются параметры вроде --uid, --gid и --umask.

Если чуть подробнее, то:

• --uid задает идентификатор владельца файлов.
• --gid — группу.
• --umask позволяет ограничить права, которые будут отображаться через mount.

Например, более строгий umask: --umask 077 означает, что доступ фактически останется только у владельца.

А более открытый вариант: --umask 022 обычно позволяет другим пользователям читать файлы, но не изменять их.

Важно понимать: это локальное представление прав через FUSE, а не изменение S3 policy.

Когда нужен --allow-other

По умолчанию FUSE mount обычно доступен только пользователю, который его создал.

Если нужно, чтобы /mnt/storage видел, например:

• Nginx;
• Docker;
• media server;
• другой systemd-сервис;
• другой Linux-пользователь,

может понадобиться параметр: --allow-other

Он разрешает доступ к mount другим пользователям системы.

Но для этого FUSE обычно должен разрешать такую возможность через /etc/fuse.conf.

В конфигурации должна быть активна строка: user_allow_other

После этого mount можно запускать, например:

    
        
    rclone mount storage:my-bucket /mnt/storage \
--allow-other \
--vfs-cache-mode writes

Но --allow-other не стоит включать автоматически «на всякий случай».

Он расширяет локальную поверхность доступа, поэтому лучше использовать его только тогда, когда mount действительно должны видеть другие пользователи или сервисы.

Почему права Linux не заменяют S3 permissions

Это один из самых важных моментов.

Допустим, файл внутри mount выглядит так: -rw-rw-rw-

Это еще не означает, что любой пользователь сможет физически изменить объект в S3.

Фактическую запись выполняет сам процесс rclone от имени своих credentials.

Если service account не имеет PutObject, попытка записи завершится ошибкой, несмотря на локальные rw.

Аналогично, DeleteObject нужен для удаления, GetObject — для чтения, ListBucket — для просмотра содержимого.

Поэтому можно представить два независимых фильтра:

Операция должна пройти оба.

Локальные права определяют, может ли приложение обратиться к mount.

S3 policy определяет, разрешит ли backend выполнить саму операцию с объектом.

Что делать, если другой пользователь или сервис не видит mount

Типичный сценарий выглядит так: администратор выполняет ls /mnt/storage и видит файлы, а Nginx или другой сервис получает Permission denied.

В этом случае нужно последовательно проверить:

• От какого пользователя запущен rclone;
• От какого пользователя работает приложение;
• Владельца точки монтирования;
• Значения uid, gid и umask;
• Используется ли --allow-other;
• Разрешен ли user_allow_other в /etc/fuse.conf.

Например, посмотреть владельца каталога можно через ls -ld /mnt/storage, а пользователя systemd-сервиса — через его unit.

Если локальные права настроены правильно, но операция чтения или записи все равно завершается ошибкой, тогда уже нужно смотреть S3 permissions самого remote.

Параметры прав доступа

Важно: FUSE отвечает за доступ к локальной точке монтирования, а S3 policy — за реальные операции с объектами.

Запускаем rclone mount автоматически через systemd

Ручное монтирование уже работает, VFS cache настроен, права доступа понятны. Но в таком виде rclone mount все еще зависит от конкретной shell-сессии: процесс нужно запускать вручную, следить за ним и поднимать заново после перезагрузки сервера.

Для production это неудобно.

Поэтому следующий шаг — передать управление процессом systemd. Тогда mount будет стартовать автоматически, работать от нужного пользователя, перезапускаться после сбоев и писать логи в стандартный журнал системы.

Почему --daemon недостаточно для production

У rclone есть параметр --daemon, который отправляет процесс в фон.

Для быстрой проверки это удобно: команда не занимает терминал, а mount продолжает работать.

Но для постоянного серверного использования у такого подхода есть ограничения.

Сам по себе --daemon не решает несколько важных задач:

• Не запускает mount автоматически после перезагрузки;
• Не контролирует состояние процесса;
• Не задает единое место для логов;
• Не перезапускает rclone после сбоя;
• Не описывает зависимости от сети;
• Не фиксирует, от какого пользователя должен работать mount.

То есть --daemon просто переводит процесс в фон, но не превращает его в полноценный управляемый сервис.

Поэтому для production удобнее использовать systemd.

Создаем отдельный systemd unit

Systemd управляет сервисами через unit-файлы.

Для нашего mount можно создать, например: /etc/systemd/system/rclone-storage.service

В нем будут описаны:

• Когда запускать сервис;
• От какого пользователя;
• Какую команду выполнять;
• Как размонтировать bucket;
• Что делать при сбое.

Пример unit-файла:

    
        
    [Unit]
Description=Rclone S3 Mount
Wants=network-online.target
After=network-online.target
[Service]
Type=notify
User=ubuntu
ExecStart=/usr/bin/rclone mount storage:my-bucket /mnt/storage \
--config=/home/ubuntu/.config/rclone/rclone.conf \
--vfs-cache-mode=writes \
--cache-dir=/var/cache/rclone \
--vfs-cache-max-size=10G \
--vfs-cache-max-age=24h
ExecStop=/bin/fusermount3 -u /mnt/storage
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

Значения User, пути к конфигурации, точке монтирования и cache нужно заменить на актуальные для своей системы.

Теперь разберем, почему отдельные строки здесь особенно важны.

Почему важны User, ExecStart и ExecStop

Параметр User= определяет, от какого Linux-пользователя будет работать rclone.

Например: User=ubuntu

Это влияет сразу на несколько вещей:

• Доступ к rclone.conf;
• Доступ к /mnt/storage;
• Доступ к VFS cache;
• Владельца FUSE mount.

Если вручную rclone запускался от пользователя ubuntu, логично использовать того же пользователя и в systemd.

ExecStart= содержит саму команду монтирования.

Здесь лучше указывать абсолютные пути: /usr/bin/rclone, а не просто: rclone

Потому что systemd не обязан использовать то же окружение и PATH, что интерактивная shell-сессия.

То же относится к конфигурации. Лучше явно указать:

--config=/home/ubuntu/.config/rclone/rclone.conf

Тогда сервис не будет зависеть от того, какой HOME systemd определил для процесса.

ExecStop= нужен для аккуратного размонтирования:

ExecStop=/bin/fusermount3 -u /mnt/storage

Если просто завершить процесс без корректного unmount, точка монтирования может остаться в неконсистентном состоянии до очистки FUSE.

Именно поэтому явный ExecStop делает остановку сервиса предсказуемее.

Как дождаться сети перед запуском

Теперь возникает следующий вопрос: что произойдет, если systemd запустит rclone раньше, чем сервер получит рабочее сетевое подключение?

Для удаленного S3 mount это критично, потому что без сети rclone не сможет обратиться к endpoint.

Поэтому в секции [Unit] полезно использовать:

    
        
    Wants=network-online.target
After=network-online.target

After= задает порядок запуска: rclone должен стартовать после достижения network-online.target.

Wants= добавляет соответствующую зависимость.

Это не означает абсолютную гарантию, что конкретный S3 endpoint уже доступен в ту же миллисекунду. Но systemd хотя бы не будет сознательно запускать remote mount до подготовки сетевого окружения.

Если провайдер или DNS временно недоступен, дальнейшую надежность обеспечивает уже перезапуск сервиса.

Как автоматически перезапускать mount после сбоя

Даже при стабильной сети удаленный mount может временно потерять соединение.

Например:

• endpoint недоступен;
• произошел сетевой сбой;
• процесс rclone завершился с ошибкой;
• FUSE mount неожиданно остановился.

Чтобы systemd не оставлял сервис выключенным, добавим:

    
        
    Restart=on-failure
RestartSec=5

Restart=on-failure означает, что systemd попробует запустить процесс снова, если тот аварийно завершился.

RestartSec=5 добавляет небольшую паузу между попытками.

Это лучше, чем бесконечный немедленный restart: если проблема внешняя, например endpoint временно недоступен, сервис не будет создавать плотный цикл перезапуска.

При этом обычная ручная команда systemctl stop rclone-storage не должна восприниматься как сбой, поэтому on-failure здесь удобнее, чем безусловный always.

Где смотреть логи

Когда rclone работает через systemd, отдельный терминал с выводом больше не нужен.

Основные сообщения попадают в journal.

Посмотреть текущий статус можно так:

sudo systemctl status rclone-storage

Здесь видно:

• Запущен ли сервис;
• PID процесса;
• Последние сообщения;
• Причину последнего сбоя, если он был.

Для подробного журнала используется:

sudo journalctl -u rclone-storage

А для просмотра событий в реальном времени:

sudo journalctl -u rclone-storage -f

Это особенно удобно при отладке mount: можно одновременно обращаться к /mnt/storage из другого терминала и видеть, какие ошибки появляются у rclone.

Если сервис не запускается, первым делом стоит проверить именно systemctl status и journalctl, а уже потом повторно менять unit-файл.

Практика: создаем и запускаем systemd service

Создадим unit:

sudo nano /etc/systemd/system/rclone-storage.service

Добавим конфигурацию:

    
        
    [Unit]
Description=Rclone S3 Mount
Wants=network-online.target
After=network-online.target
[Service]
Type=notify
User=ubuntu
ExecStart=/usr/bin/rclone mount storage:my-bucket /mnt/storage \
--config=/home/ubuntu/.config/rclone/rclone.conf \
--vfs-cache-mode=writes \
--cache-dir=/var/cache/rclone \
--vfs-cache-max-size=10G \
--vfs-cache-max-age=24h
ExecStop=/bin/fusermount3 -u /mnt/storage
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

После сохранения перечитаем конфигурацию systemd:

sudo systemctl daemon-reload

Теперь включим автоматический запуск и сразу стартуем сервис:

sudo systemctl enable --now rclone-storage

Проверим состояние:

sudo systemctl status rclone-storage

Затем убедимся, что mount действительно появился:

findmnt /mnt/storage

И посмотрим содержимое:

ls -la /mnt/storage

Если нужно посмотреть журнал:

sudo journalctl -u rclone-storage

А для live-режима:

sudo journalctl -u rclone-storage -f

Команды из главы

Теперь mount уже не зависит от открытого SSH-сеанса и может автоматически подниматься вместе с сервером.

Какие ограничения есть у S3 mount

После настройки systemd mount уже выглядит почти как полноценный сетевой диск: каталог появляется автоматически, приложения видят обычные пути, а rclone скрывает большую часть работы с S3 API.

Но здесь важно не потерять исходную архитектуру из виду.

Под /mnt/storage по-прежнему находится не ext4, XFS или NFS, а Object Storage. Поэтому некоторые операции, которые на обычной файловой системе стоят почти ничего, в S3 могут требовать дополнительных запросов, копирования объектов или повторной загрузки данных.

Именно эти различия определяют, для каких задач rclone mount подходит хорошо, а где начинает мешать.

Почему rename и move могут быть дорогими

В обычной файловой системе переименование файла часто сводится к изменению метаданных.

Если файл размером 20 ГБ переименовать внутри одного раздела, сами 20 ГБ данных обычно никуда не копируются.

В S3 имя объекта — это его key.

Поэтому изменение условного пути archive/old.tar.gz на archive/new.tar.gz не всегда может быть выполнено как простое переименование.

Для backend такая операция может фактически означать: создать объект с новым key, скопировать туда данные и затем удалить старый объект.

Для одного небольшого файла разница практически незаметна.

Но если приложение массово перемещает большие файлы или переименовывает целые «каталоги», стоимость операции уже может значительно вырасти по времени, трафику и количеству S3-запросов.

Особенно важно помнить, что каталог в S3 — это в основном общий префикс key. Поэтому переименование каталога с тысячами объектов потенциально превращается в обработку этих объектов по отдельности.

Почему запись маленькими блоками работает не как на обычном диске

Локальная файловая система хорошо приспособлена к изменению отдельных участков файла.

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

Object Storage работает с объектами иначе.

S3 API ориентирован прежде всего на загрузку, получение и удаление объектов, а не на произвольное изменение отдельных дисковых блоков.

Поэтому когда приложение пишет через rclone mount, rclone приходится адаптировать файловую модель к объектной.

Здесь как раз помогает VFS cache: изменения можно временно выполнять на локальном диске, а уже затем отправлять итоговое состояние в S3.

Но фундаментального свойства это не меняет. Под капотом всё равно нет удаленного блочного устройства, в которое можно дешево записать несколько килобайт в произвольное место.

Поэтому приложения с большим количеством мелких частичных записей обычно чувствуют себя на S3 mount хуже, чем на настоящей файловой системе.

Почему случайный доступ и частые изменения файлов могут быть медленнее

С чтением ситуация похожая.

Последовательное чтение большого объекта хорошо соответствует модели Object Storage: rclone получает данные через сеть и передает их приложению.

Но если программа постоянно прыгает по разным участкам файла, часто открывает и закрывает его или изменяет содержимое небольшими порциями, возрастает роль:

• Сетевой задержки;
• VFS cache;
• Количества API-запросов;
• Локального диска;
• Размера файлов.

Режим --vfs-cache-mode full способен заметно улучшить такой сценарий, потому что часть данных оказывается локально.

Но тогда mount начинает зависеть уже не только от производительности S3, но и от размера и скорости локального cache.

Получается своеобразный компромисс: чем сильнее мы пытаемся приблизить S3 к обычному диску, тем больше локальных ресурсов нужно rclone для этой эмуляции.

Поэтому S3 mount особенно хорошо подходит для данных, которые относительно редко изменяются и чаще читаются целиком.

Что происходит с файловыми блокировками

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

На обычной POSIX-файловой системе это часть ожидаемой модели работы.

У S3 такой встроенной семантики нет.

rclone может реализовывать часть ожидаемого поведения на уровне своего VFS, но это не превращает удаленное Object Storage в распределенную файловую систему с полноценными POSIX locks.

Особенно опасно рассчитывать на такие блокировки, если один и тот же bucket одновременно доступен через:

• Несколько независимых rclone mount;
• AWS CLI;
• Приложение по S3 API;
• Панель провайдера.

Один клиент может просто не знать о локальной блокировке, созданной другим клиентом.

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

Почему базы данных лучше не размещать поверх S3 mount

База данных — почти идеальный пример нагрузки, которая плохо совпадает с объектной моделью.

СУБД ожидает от файловой системы вполне конкретное поведение:

• Быстрые случайные чтения и записи;
• Частое изменение небольших участков файлов;
• Надежный fsync;
• Предсказуемую задержку;
• Корректные блокировки;
• Строгую семантику операций с файлами.

S3 mount не может гарантированно превратить Object Storage в такой тип блочного хранилища.

VFS cache способен замаскировать часть различий, но между СУБД и фактическим объектом всё равно остается дополнительный слой с сетью и API.

Поэтому PostgreSQL, MySQL, SQLite и другие активно изменяемые базы лучше хранить на локальном или сетевом блочном/файловом хранилище, которое соответствует их требованиям.

Object Storage при этом отлично подходит для другого этапа — например, для хранения дампов и резервных копий базы.

И это как раз подводит нас к важному вопросу: если данные не обязательно должны быть доступны как постоянно смонтированный каталог, возможно, mount вообще не лучший инструмент.

Когда лучше использовать rclone sync, а не mount

В каких случаях mount действительно удобен

Rclone mount хорошо подходит, когда программе нужен обычный файловый путь.

Например, приложение ожидает получать данные из /mnt/storage/media, но само не умеет работать с S3 API.

В таком случае mount становится адаптером между приложением и Object Storage.

Хорошими кандидатами могут быть:

• Медиатеки;
• Архивы документов;
• Каталоги с изображениями;
• Данные преимущественно для чтения;
• Редко изменяемые большие файлы;
• Административный просмотр содержимого удаленного хранилища.

То есть mount особенно полезен, когда важна постоянная видимость удаленных объектов как файлов.

Когда sync надежнее и проще

Если постоянная точка монтирования не нужна, rclone sync часто оказывается значительно проще.

При sync нет постоянно работающего FUSE-процесса, не требуется поддерживать mount после потери сети и обычно не нужен большой VFS cache.

Сценарий становится понятнее: есть источник, есть назначение, в определенный момент rclone синхронизирует их.

Например, можно раз в час отправлять каталог в Object Storage через systemd timer или cron.

После завершения команды локальное приложение продолжает работать с обычной файловой системой и никак не зависит от доступности S3.

Это делает sync особенно удобным там, где Object Storage используется как удаленная копия, а не как рабочая файловая система.

Почему backup и архивы часто лучше синхронизировать

Для резервного копирования постоянный mount обычно вообще не нужен.

Если backup создается локально как backup.tar.gz, проще после завершения выгрузить его в S3 через rclone copy или синхронизировать каталог через rclone sync.

Тогда процесс можно четко разделить на этапы: сначала локально создается корректная резервная копия, затем готовый файл отправляется в удаленное хранилище.

Это зачастую надежнее, чем заставлять backup-программу напрямую работать поверх FUSE mount.

То же относится к архивам.

Если файлы формируются локально, а затем должны просто попасть в Object Storage для долгого хранения, mount не дает особого преимущества.

Зато добавляет дополнительные зависимости: FUSE, systemd service, VFS cache и постоянное соединение.

Когда нужен постоянный файловый доступ, а когда достаточно периодической выгрузки

Выбор можно свести к одному вопросу: Должно ли приложение постоянно видеть удаленные данные как часть своей файловой системы?

Если да, mount может быть оправдан.

Если задача звучит как «раз в N минут отправить новые файлы в S3», гораздо естественнее использовать sync.

То же самое работает и в обратную сторону. Если локальному серверу достаточно периодически получать актуальную копию удаленного каталога, можно синхронизировать S3 → локальный диск и работать уже с обычной файловой системой.

Так приложение не зависит от сетевой задержки при каждом open() или read().

Что выбрать 

Так что же по итогу выбрать? Для ответа на этот вопрос составил удобную таблицу которая поможет дать ответ на этот вопрос:

У mount и sync поэтому нет конкуренции в прямом смысле. Первый предоставляет постоянный файловый интерфейс, второй переносит состояние между двумя хранилищами.

Если этот выбор сделать правильно заранее, можно избежать большей части проблем с производительностью и неожиданным поведением S3 mount.

Теперь остается собрать все настроенные компоненты вместе и провести финальную проверку: от доступа к remote до постоянного mount под управлением systemd.

Проверяем работу схемы целиком

Все основные компоненты уже настроены по отдельности: remote подключается к S3-compatible endpoint, FUSE позволяет представить bucket как каталог Linux, VFS cache сглаживает различия между файловой и объектной моделью, а systemd отвечает за постоянный запуск.

Теперь полезно один раз пройти всю цепочку целиком. Такая проверка позволяет убедиться, что проблема не скрывается на стыке нескольких компонентов.

Для примеров продолжим использовать remote storage, bucket my-bucket и точку монтирования /mnt/storage.

Сначала проверим сам rclone, еще не затрагивая FUSE. Remote должен отображаться в конфигурации, а содержимое bucket — читаться напрямую через S3 API.

Если эти команды работают, значит endpoint, credentials и базовые права доступа настроены правильно. Теперь можно переходить к локальной стороне и проверить ручное монтирование.

Создадим точку монтирования, если ее еще нет, и передадим ее пользователю, от которого запускается rclone. Затем запустим mount с теми же параметрами VFS cache, которые планируем использовать постоянно.

sudo mkdir -p /mnt/storage

sudo chown $USER:$USER /mnt/storage

    
        
    rclone mount storage:my-bucket /mnt/storage \
--vfs-cache-mode writes \
--cache-dir /var/cache/rclone \
--vfs-cache-max-size 10G \
--vfs-cache-max-age 24h

Поскольку rclone остается в foreground, дальнейшую проверку удобнее выполнять во втором SSH-сеансе.

Последняя команда особенно полезна: она проверяет результат в обход FUSE. Если rclone-test.txt появился при просмотре remote, значит файл действительно отправлен в Object Storage, а не существует только в локальном представлении mount.

При включенном VFS cache можно дополнительно посмотреть каталог кэша:

du -sh /var/cache/rclone

Но нужно учитывать, что содержимое VFS cache меняется динамически. После успешной загрузки rclone может очистить ненужные данные, поэтому отсутствие тестового файла в cache не означает, что VFS не работает.

После проверки ручной mount больше не нужен. Остановим его через Ctrl+C в терминале с rclone или размонтируем из второго сеанса:

fusermount3 -u /mnt/storage

Теперь начинается последняя часть проверки — тот же mount должен подняться уже не вручную, а через созданный ранее systemd unit.

Если сервис имеет состояние active, findmnt показывает /mnt/storage, а созданный ранее файл по-прежнему читается, вся схема работает целиком:

Для окончательной проверки автозапуска можно перезагрузить сервер и после подключения повторно выполнить:

sudo systemctl status rclone-storage

findmnt /mnt/storage

ls -la /mnt/storage

Если mount появился без ручного запуска rclone, systemd-конфигурация переживает перезагрузку и готова к постоянному использованию.

Тестовый объект после проверки можно удалить обычной файловой командой:

rm /mnt/storage/rclone-test.txt

Либо напрямую через rclone:

rclone deletefile storage:my-bucket/rclone-test.txt

После этой проверки техническая настройка завершена. Остается последний production-слой: защитить rclone.conf и credentials, ограничить права service account, следить за размером VFS cache и не использовать S3 mount в тех сценариях, где приложению действительно нужна полноценная POSIX-файловая система.

Как безопасно использовать rclone mount в production

Не хранить конфигурацию с credentials в общедоступном месте

Файл rclone.conf нужно считать секретным.

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

В ней могут находиться:

• Access Key;
• Secret Key;
• Endpoint;
• Параметры remote;
• Дополнительные сведения о подключении.

Поэтому конфигурацию не стоит помещать в общий каталог проекта, добавлять в Git или копировать в публичные инструкции.

Для systemd удобнее хранить ее в отдельном пользовательском каталоге и явно указывать путь через --config.

Например:

/home/ubuntu/.config/rclone/rclone.conf

Сам файл желательно сделать доступным только владельцу:

chmod 600 ~/.config/rclone/rclone.conf

Если rclone запускается от отдельного системного пользователя, конфигурация должна принадлежать именно ему.

Таким образом доступ к mount не будет автоматически означать доступ к credentials, которыми этот mount обслуживается.

Ограничить права отдельного service account

Следующий слой защиты находится уже на стороне Object Storage.

Для rclone mount лучше создать отдельный service account и выдать ему только те действия, которые действительно нужны.

Например, если каталог используется только для чтения медиа, service account может не нуждаться в PutObject и DeleteObject.

Если mount должен позволять загрузку файлов, но удаление нежелательно, можно оставить запись без права удаления.

Это особенно важно потому, что локальная команда вроде rm в /mnt/storage в итоге преобразуется в S3-операцию.

Если credentials имеют DeleteObject, удаление будет выполнено и на стороне Object Storage.

Если такого права нет, S3 API станет дополнительным предохранителем.

Поэтому production remote лучше строить по принципу минимальных прав: один сервис — один service account — один конкретный набор разрешений.

Контролировать размер VFS cache

VFS cache делает mount заметно удобнее, но одновременно добавляет новую локальную точку риска.

Если размер кэша не контролировать, он может постепенно занять значительную часть системного диска.

Для небольшого VPS это особенно неприятно: заполненный раздел может затронуть не только rclone, но и systemd journal, базы данных, Docker и другие сервисы.

Поэтому параметры вроде --vfs-cache-max-size и --vfs-cache-max-age лучше задавать сразу, а не после первого переполнения диска.

Например:

--vfs-cache-max-size 10G

--vfs-cache-max-age 24h

При этом лимит нужно выбирать не от размера bucket, а от свободного пространства на локальном разделе и характера нагрузки.

Если приложение регулярно работает с файлами по 20–30 ГБ, кэш в 5 ГБ может оказаться слишком маленьким даже при огромном Object Storage.

Контролировать использование диска можно обычными средствами Linux, например через df -h и du -sh /var/cache/rclone.

Следить за логами и переподключениями

Удаленное хранилище зависит от сети, DNS и доступности самого S3 endpoint.

Поэтому кратковременные ошибки соединения в production полностью исключить нельзя.

Важно другое: сервис должен корректно восстанавливаться после них, а администратор — иметь возможность понять, что произошло.

Для этого мы уже добавили в systemd: Restart=on-failure и RestartSec=5

Теперь остается периодически смотреть логи.

Быстрая проверка состояния выполняется через systemctl status rclone-storage, а более подробная история доступна в journalctl -u rclone-storage.

Особое внимание стоит обращать на повторяющиеся:

• Ошибки авторизации;
• Проблемы с endpoint;
• Таймауты;
• Сообщения FUSE;
• Ошибки заполнения cache;
• Циклические перезапуски сервиса.

Одиночный сетевой timeout и десятки рестартов за час — совершенно разные ситуации.

Поэтому systemd здесь нужен не только для автозапуска, но и как удобная точка наблюдения за состоянием mount.

Не использовать S3 mount там, где нужна настоящая POSIX-файловая система

Последнее правило — пожалуй, самое важное.

Хорошо настроенный rclone mount не превращает Object Storage в ext4, XFS или NFS.

Если приложение критически зависит от:

• Строгой файловой блокировки;
• Стабильного fsync;
• Очень низкой задержки;
• Частых случайных записей;
• Изменения небольших блоков больших файлов;
• Сложной POSIX-семантики,

Лучше сразу выбрать подходящее блочное или файловое хранилище.

Не стоит пытаться исправить архитектурное несоответствие все более агрессивными настройками VFS cache.

rclone mount хорош там, где нужен удобный файловый интерфейс поверх объектного хранилища.

А там, где приложению действительно нужен настоящий диск, лучше дать ему настоящий диск.

Заключение

Rclone mount позволяет представить S3-совместимое Object Storage как обычный каталог Linux и работать с удаленными объектами через привычные файловые пути.

В статье мы настроили всю цепочку: установили rclone и FUSE, создали S3-compatible remote с собственным endpoint, проверили соединение, смонтировали bucket, добавили VFS cache, настроили права и автоматический запуск через systemd.

При этом S3 после монтирования не становится полноценной POSIX-файловой системой. Для резервных копий, архивов и периодической передачи данных часто проще использовать rclone sync или rclone copy, а mount оставлять для сценариев, где действительно нужен постоянный файловый доступ.

Если учитывать эти ограничения, контролировать VFS cache и не выдавать remote лишние права, rclone становится удобным и предсказуемым мостом между Linux и S3-compatible Object Storage.

FAQ

Можно ли использовать rclone mount без VFS cache?

Да, но совместимость с обычными файловыми операциями будет ограничена. Без VFS cache rclone хуже работает со случайной записью, повторным открытием файла и некоторыми другими сценариями. Для приложений, которые записывают данные через mount, разумной отправной точкой обычно становится --vfs-cache-mode writes.

Почему файл виден через rclone, но другой Linux-пользователь не может его открыть?

Чаще всего причина находится на уровне FUSE, а не S3. По умолчанию mount связан с пользователем, который его создал. Если доступ нужен другим пользователям или сервисам, может потребоваться --allow-other и разрешение user_allow_other в /etc/fuse.conf.

При этом отдельно нужно учитывать права самого S3 service account: локальные разрешения Linux и доступ к объектам в хранилище — это два разных уровня.

Можно ли хранить базу данных непосредственно на S3 через rclone mount?

Для активно работающих PostgreSQL, MySQL, SQLite и подобных СУБД такой вариант лучше не использовать. S3 остается объектным хранилищем и не предоставляет ту же семантику случайной записи, fsync, блокировок и низкой задержки, которую база ожидает от обычной файловой системы.

Object Storage гораздо лучше подходит для хранения дампов и резервных копий базы.

Что выбрать для резервных копий: rclone mount или rclone sync?

Если резервная копия сначала создается локально, а затем ее нужно отправить в Object Storage, обычно проще использовать rclone sync или rclone copy.

mount имеет смысл, когда приложению действительно нужен постоянно доступный файловый путь. Для периодической передачи готовых файлов FUSE, VFS cache и постоянно работающий сервис чаще оказываются лишними.

Почему VFS cache может занять больше места, чем указано в --vfs-cache-max-size?

Лимит не является мгновенной жесткой границей. rclone периодически проверяет кэш, а открытые файлы нельзя просто удалить из него во время использования. Поэтому фактический размер временно может превысить установленное значение. Именно поэтому на локальном разделе стоит оставлять дополнительный запас свободного пространства.

Что произойдет с mount после перезагрузки сервера?

Если запускать rclone mount вручную, после перезагрузки его придется запускать заново.

Для постоянной работы удобнее передать управление systemd: сервис сможет автоматически запускать rclone после загрузки системы, следить за процессом и перезапускать его при сбое.

Почему изменения в S3 иногда не сразу появляются в смонтированном каталоге?

rclone кэширует сведения о каталогах, чтобы не обращаться к удаленному API при каждой файловой операции. Поэтому изменение, выполненное напрямую через панель провайдера, другой экземпляр rclone или сторонний S3-клиент, может появиться в mount не мгновенно.

На время обновления влияет кэш каталогов и возможности конкретного backend по отслеживанию внешних изменений.

Можно ли один и тот же VFS cache использовать для нескольких rclone mount?

Если несколько экземпляров rclone работают с пересекающимися remote и используют VFS cache, общий каталог кэша лучше не делить между ними. Документация rclone предупреждает, что это потенциально может привести к повреждению данных. Для отдельных mount безопаснее задавать разные каталоги через --cache-dir.

Список источников

1. rclone Documentation — rclone mount
2. rclone Documentation — Amazon S3 Storage Providers
3. rclone Documentation — General Documentation
4. libfuse — FUSE API Documentation