Бэкапы на Яндекс.Диск из KDE (Kup backup и davfs2)

[MaKcuMoB]

Всем привет!

При попытке резервного копирования с помощью Kup backup на смонтированный Яндекс.Диск через davfs2 возникает ошибка и "подвисает" вся папка /media, т.е. более невозможно в неё зайти.

Монтирую Яндекс.Диск так:

/etc/fstab

Код: [Выделить]

https://webdav.yandex.ru /media/Yandex davfs user,rw,noauto 0 0

в автозапуске скрипт:

Код: [Выделить]

#!/bin/bash
sleep 120 && mount /media/Yandex
Диск монтируется нормально, все файлы доступны, права правильные.

При попытке положить туда бэкап пишет ошибку, а влоге вот такое:

Код: [Выделить]

Kup is starting bup backup job at понедельник, 14 октября 2019 г. 0:03:04 MSK

bup "-d" "/media/Yandex/backup/work_laptop" "init"
bup "-d" "/media/Yandex/backup/work_laptop" "fsck" "--quick"
bup "-d" "/media/Yandex/backup/work_laptop" "index" "-u" "/home/maksymov/Документы" "/home/maksymov/Скрипты"
bup "-d" "/media/Yandex/backup/work_laptop" "save" "-n" "kup" "-vv" "/home/maksymov/Документы" "/home/maksymov/Скрипты"
Traceback (most recent call last):
  File "/usr/lib/bup/cmd/bup-save", line 460, in <module>
    w.close()  # must close before we can update the ref
  File "/usr/lib/bup/bup/git.py", line 790, in close
    return self._end(run_midx=run_midx)
  File "/usr/lib/bup/bup/git.py", line 768, in _end
    obj_list_sha = self._write_pack_idx_v2(self.filename + '.idx', idx, packbin)
  File "/usr/lib/bup/bup/git.py", line 806, in _write_pack_idx_v2
    idx_map = mmap_readwrite(idx_f, close=False)
  File "/usr/lib/bup/bup/helpers.py", line 770, in mmap_readwrite
    close)
  File "/usr/lib/bup/bup/helpers.py", line 752, in _mmap_do
    map = mmap.mmap(f.fileno(), sz, flags, prot)
mmap.error: [Errno 19] No such device
При этом на флешку бэкапится без проблем.

В чём может быть причина и как лечить?
Пользователь добавил сообщение 16 Октября 2019, 10:58:10:Вот такой ответ получил от разработчика, будем ждать...

I suspect the problem might be that bup currently depends heavily on
mmap, and perhaps davfs2 (or fuse if that's what's underneath) doesn't
support it well enough yet.

(I've done some work to allow bup to fall back to non-mmap approaches
 when mmap fails, but it's not finished, and I haven't worked on it for
 a while.)

If that's the case, then I imagine it might not be sufficient, but if
you could afford the extra copy of the backup, you could probably backup
to a local drive and then rsync to davfs2, but then in an emergency, you
might have to rsync the whole repository back to a local drive before you
could restore.

For what it's worth, I might try to pick the mmap fallback work back up
after we finish the python 3 port (assuming that's actually the problem
here)...