Автомонтування Google Drive через rclone на Debian + GNOME: історія для однієї філіжанки кави

Захотілося простого: підключити Google Drive як звичайну папку в файловій системі, і щоб воно саме піднімалось при вході в систему, без танців з бубном щоразу. Здавалося б, rclone mount — і готово. Виявилось трохи цікавіше.

Крок 1. rclone і конфіг, якого нема

Перша спроба:

rclone mount gdrive: ~/GDrive --daemon

У відповідь:

Failed to create file system for "gdrive:": didn't find section in config file

Логічно — remote gdrive в конфізі просто не існував. Створити порожній файл командою rclone config touch теж не рятує: файл є, секції нема.

Рішення: інтерактивний майстер rclone config. Він сам генерує правильну секцію в ~/.config/rclone/rclone.conf і проводить через OAuth-авторизацію в браузері — 2FA при цьому обробляється звичайним способом, через сам Google, rclone до неї жодного стосунку не має. На машині з GUI (а в мене GNOME) достатньо погодитись на Use auto config? (y) — rclone підійме локальний вебсервер і сам відкриє браузер для логіну.

Крок 2. Автозапуск при логіні — перша перешкода: D-Bus

Щоб не монтувати вручну щоразу, оформив systemd user-юніт:

[Unit]
Description=RClone mount Google Drive
AssertPathIsDirectory=%h/GDrive
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/rclone mount gdrive: %h/GDrive \
    --vfs-cache-mode writes \
    --config=%h/.config/rclone/rclone.conf
ExecStop=/bin/fusermount -u %h/GDrive
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

І одразу вперся в:

Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

Спробував виставити loginctl enable-linger, спробував вручну експортувати змінні — не допомагало. Причина виявилась банальною і трохи соромною: у .bashrc завалявся старий

alias systemctl='sudo systemctl'

А sudo за замовчуванням очищує середовище процесу. Тобто щойно виставлені XDG_RUNTIME_DIR і DBUS_SESSION_BUS_ADDRESS до команди просто не доходили — sudo їх зрізав ще до старту systemctl. Найприкріше, що для керування власними user-юнітами (systemctl --user) права root взагалі не потрібні.

Рішення: викликати бінарник напряму, оминаючи alias:

/usr/bin/systemctl --user daemon-reload
/usr/bin/systemctl --user enable --now rclone-gdrive.service

І заразом не завадить loginctl enable-linger <user> — щоб user-сесія (і user-юніти) піднімались навіть без активного графічного логіну.

Крок 3. Сервіс стартує і одразу падає

Failed to create file system for "gdrive:": didn't find section in config file

Та сама помилка, що й на самому початку — але тепер конфіг точно існував. Загадка розкрилась при прямому запуску команди в терміналі (без --daemon, щоб бачити живий вивід):

/usr/bin/rclone mount gdrive: ~/GDrive --vfs-cache-mode writes --config=/home/olden/.config/rclone/rclone.conf

Та сама помилка. Але варто було спробувати з великої літери:

/usr/bin/rclone mount GDrive: ~/GDrive --vfs-cache-mode writes --config=/home/olden/.config/rclone/rclone.conf

— і диск підключився. rclone чутливий до регістру назви remote, а в конфізі секція виявилась записана як [GDrive], а не [gdrive], як я вважав. Дрібниця, яка коштувала половини вечора.

Виправив у юніті:

sed -i 's/rclone mount gdrive:/rclone mount GDrive:/' ~/.config/systemd/user/rclone-gdrive.service

Крок 4. Порожня папка після, здавалося б, вдалого монтування

Сервіс піднявся, systemctl --user status показував active (running), а ls ~/GDrive — порожньо. При тому ручний запуск хвилиною раніше показував повний список файлів.

Причина — накладені (stale) точки монтування. Я тестував ручний запуск rclone mount просто в терміналі, потім намагався його відмонтувати через fusermount3 -u, але процес до кінця не прибрався. Коли systemd підняв новий rclone mount поверх недомонтованого старого шару, ядро показувало нову, ще порожню точку.

Розібратись допомогла така послідовність:

/usr/bin/systemctl --user stop rclone-gdrive.service
fusermount3 -u ~/GDrive          # повторити кілька разів, якщо треба
pkill -f "rclone mount"          # добити зомбі-процеси
ps aux | grep rclone             # переконатись, що чисто
/usr/bin/systemctl --user start rclone-gdrive.service

Після цього ls ~/GDrive нарешті показав реальні файли.

Підсумок: робочий юніт

[Unit]
Description=RClone mount Google Drive
AssertPathIsDirectory=%h/GDrive
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/rclone mount GDrive: %h/GDrive \
    --vfs-cache-mode writes \
    --config=%h/.config/rclone/rclone.conf
ExecStop=/bin/fusermount -u %h/GDrive
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

loginctl enable-linger $USER
/usr/bin/systemctl --user daemon-reload
/usr/bin/systemctl --user enable --now rclone-gdrive.service

(Type=notify теж мав шанс спрацювати — версія rclone тут доволі свіжа, — але коли шукаєш причину падіння, простіше тимчасово спростити до Type=simple, щоб виключити зайву змінну з рівняння.)

Висновки на майбутнє

• Alias на sudo systemctl і systemctl --user — погана комбінація. Sudo зрізає середовище, а --user-юнітам права root взагалі не потрібні.
• rclone чутливий до регістру назв remote. gdrive: і GDrive: — це два різні (точніше, один існуючий і один неіснуючий) remote.
• Перед діагностикою systemd-юніта корисно спершу прогнати ту саму команду вручну в терміналі — так помилка видно одразу, без прошарку journalctl.
• Stale FUSE-монтування — підступна штука: systemctl status може казати active (running), а точка монтування при цьому виявиться порожньою, бо накладена на недомонтований попередній шар. pkill -f + чистий stop/start знімає це надійно.

Дрібниця на дрібниці, але кожна — окрема пастка, у яку легко провалитись саме тому, що симптом (одна й та сама помилка «not found in config file») мав дві геть різні причини на різних етапах.