Ситуация (что было)

  • Подключали к ноутбуку камеру (Canon/USB PTP): в dmesg она определялась как USB PTP Camera.
  • При запуске скрипта canon.sh команда gphoto2 --get-all-files падала с ошибкой:

> Помилка у бібліотеці вводу-виводу ('Не вдалося отримати контроль над пристроєм USB'): Не вдалося захопити інтерфейс 0 (Пристрій або ресурс зайнято).

  • Сообщение явно указывало, что устройство занято другим процессом или модулем ядра.
  • Проверка ps aux | egrep 'gphoto|gvfs' показала целый набор gvfs‑демонов, в том числе:
  • /usr/lib/gvfs-gphoto2-volume-monitor
  • /usr/lib/gvfsd-gphoto2 ...
  • То есть окружение (GNOME/другое) автоматически перехватывало PTP‑камеру через gvfs и блокировало интерфейс для gphoto2.

Что сделали (рабочее решение)

Разовый запуск (диагностика и временное решение)

Для проверки и одноразового запуска мы:

1. Остановили сервис‑монитор gphoto2 в пользовательской сессии:

   systemctl --user stop gvfs-gphoto2-volume-monitor.service 2>/dev/null || true

2. Добили уже запущенные процессы, которые держали камеру:

   pkill -f gvfsd-gphoto2 || true
   pkill -f gvfs-gphoto2-volume-monitor || true

3. После этого переподключили камеру и снова запустили ./canon.sh — gphoto2 успешно забрал интерфейс и скачал файлы.

Рекомендации для постоянной работы

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

Вариант 1: Полностью отключить автоподключение камер через gvfs (рекомендуется, если камера используется только через gphoto2/скрипты)

1. Маскируем сервис‑монитор в user‑systemd:

   systemctl --user stop gvfs-gphoto2-volume-monitor.service
   systemctl --user mask gvfs-gphoto2-volume-monitor.service

2. Перелогиниться или перезагрузить сессию.

3. Проверка:

   systemctl --user list-unit-files | grep gvfs-gphoto2
   ps aux | grep gphoto2

Должно быть:

  • gvfs-gphoto2-volume-monitor.service в состоянии masked.
  • Нет работающих процессов gvfs-gphoto2-volume-monitor/gvfsd-gphoto2 (пока сам их не запустишь/не размаскируешь).

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

Вариант 2: Жёстко вырубить backend gvfs для gphoto2

Если хочешь гарантированно, чтобы gvfs вообще никогда не лез к камерам:

1. Сделать бинарники неисполняемыми:

   sudo chmod -x /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
   sudo chmod -x /usr/lib/gvfs/gvfsd-gphoto2

2. Перезагрузить систему.

После этого:

  • Файловый менеджер не будет автоматически открывать PTP‑камеры.
  • gphoto2 будет единственным, кто работает с камерой по PTP.

Вариант 3: Отключать gvfs только на время работы скрипта

Если иногда всё же нужно автоподключение камер в файловом менеджере, но при запуске canon.sh хочешь чистый доступ для gphoto2, можно встроить «чистку» прямо в скрипт.

В начало canon.sh добавить, например:

#!/bin/bash

# убиваем всё, что может держать PTP-камеру
systemctl --user stop gvfs-gphoto2-volume-monitor.service 2>/dev/null || true
pkill -f gvfsd-gphoto2 2>/dev/null || true
pkill -f gvfs-gphoto2-volume-monitor 2>/dev/null || true

base=~/Desktop/DCIM/100CANON
mkdir -p "$base"/{cr2,jpg,mov}
cd "$base" || exit 1

gphoto2 --get-all-files || exit 2

# дальше твои mv/exiv2 как раньше...

В этом режиме:

  • Перед каждым запуском скрипта убиваются процессы, блокирующие камеру.
  • После работы скрипта окружение при следующем подключении устройства/перезапуске сессии сможет снова поднять gvfs‑демоны.

Как вернуть всё «как было» (откат изменений)

Зависит от того, какой из вариантов применён.

Если использовался Вариант 1 (mask)

Чтобы вернуть стандартное поведение gvfs:

systemctl --user unmask gvfs-gphoto2-volume-monitor.service
systemctl --user start gvfs-gphoto2-volume-monitor.service

При необходимости — перелогиниться.

Если использовался Вариант 2 (chmod)

Вернуть исполнение файлов:

sudo chmod +x /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
sudo chmod +x /usr/lib/gvfs/gvfsd-gphoto2
reboot

После ребута всё будет работать как до правок.

Если использовался Вариант 3 (изменён canon.sh)

  • Ничего в системе не ломалось, достаточно убрать лишние строки из canon.sh или закомментировать их.
  • Поведение gvfs останется стандартным.

***

[file-name 000373_2026-06-12_07-58-27.txt]