Backup fails if backup destination is not mounted

[William Ritchie]

I have set my backup destination to a separate drive in the machine, but not at the default location.

When the backup runs, it fails stating permission denied, as the destination drive is not mounted.

When I enter the proper destination in the backup at the "storage location", the drive then mounts and is present on the desktop. Then the backup will run successfully.

I then "unmount" the drive using the menu on the drive icon, and the mounted drive disappears from the desktop. I don't need a bunch of drives listed or shown on my desktop, as it detracts from the beauty of the screen.

If I mount the drive before running the backup, it will succeed.

My point with this is that I am not going to mount the drive every time I run backup, and when mounted, I don't need it listed or shown on my desktop.

In unity, the drives appeared in the launcher or dock, and there was an option to "remove from launcher", which still left the drive mounted, but off the desktop and launcher. This was a nice way to fix this problem.

[William Ritchie (incryptx)]

This was on 18.04 Beta.

[William Ritchie (incryptx)]

I tried using "Disks" to allow for the partition on which the backups live on a local drive to "mount on startup".

Instead of mounting the disk for which the partition was marked "mount on startup", at reboot, it seem to hide the drive all together. The drive was not mounted, but hidden from the system and completely unavailable to the backup application or listed in file manager.

I reversed the process by checking the box in "Disks" to allow default management, and upon reboot, the drive with the partition for the backups was back and available.

So, I cannot mount the backup drive at system startup, and the backup application, once set to "Local Device" and pointing to a local disk (other than the default) will cause the backup (if scheduled) to fail claiming it is unable to create, permission denied.

One I open the backup application and manually point the "Backup Destination" does the destination drive "mount" and the backup will succeed.

The backup cannot be scheduled to backup to a local drive other than it's default.

This is clearly broken. The "mount on startup" should have fixed this, so the backup drive is mounted and available at system startup and available for the backup application.

This is on 18.04 Beta daily builds.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Vej (vej)]

Hello everyone.

This is related to bug #804170 but goes even further. instead of preventing to run backups only if the "hard-to-detect sometimes-directories" are available it requests to make them available.

This would be a new feature.

[William Ritchie (incryptx)]

I have not found the bug you describe to be true.

Work-a-round. If you mount the backup destination before the scheduled
backup begins, everything is fine and the backup runs without error.

If you don't mount the backup destination before the scheduled backup,
it will fail, with destination does not have permissions.

The permissions on the backup destination are correct in my case. It's
just a matter of having the destination partition for backups available
by mounting it first.

Granted, it seems to be a deja-dup bug, but more to the point, it's an
OS system bug because the OS does the mounting, not deja-dup.

Deja-Dup just makes an OS system call for the partition, which gets
passed to Deja-Dup, but gets no reply from the OS system to mount the
partition or have the partition mounted at system startup. If the OS
mounts the partition at system start-up, Deja-Dup will perform as expected.

I have tried "through system startup" to have the destination partition
"auto-mount" at startup, and this works, but no reply to deja-dup is
received.

It is not a "hard-to-detect-sometimes-directories", but a OS system bug
as Deja-Dup does not get the appropriate command to mount the
destination partition, or does not reply to the OS system to mount the
partition.

Be well.

On 09/16/2018 02:00 PM, Vej wrote:
> Hello everyone.
>
> This is related to bug #804170 but goes even further. instead of
> preventing to run backups only if the "hard-to-detect sometimes-
> directories" are available it requests to make them available.
>
> This would be a new feature.
>
> ** Also affects: deja-dup
> Importance: Undecided
> Status: New
>
> ** Changed in: deja-dup
> Status: New => Confirmed
>
> ** Changed in: deja-dup (Ubuntu)
> Importance: Undecided => Wishlist
>
> ** Changed in: deja-dup
> Importance: Undecided => Wishlist
>
> ** Changed in: deja-dup (Ubuntu)
> Status: Confirmed => Triaged
>
> ** Changed in: deja-dup
> Status: Confirmed => Triaged
>
> ** Tags added: needs-design
>

[Michael Terry (mterry)]

How is this other drive configured? Is it an entry in fstab? And you were entering its path as a Local Folder storage location?

If so, we didn't previously do anything special about mounting fstab entries for you. But I just added some code to try that.

Could you give a beta build a try and see if it works for you?
`snap install deja-dup --classic --edge`

[William Ritchie (incryptx)]

Yes, it is listed in fstab and yes, I entered the path as a local
storage device.

All drives are SSD's connected to the computer's internal SSD ports and
seen as local. The server is running XIGMANAS with SMB shares for each
of the SSD's. I am not running SAMBA server.

The local OS is Unbuntu 20.04 where the backup app is running and will
not work if the backup drive partition is not mounted first. I can get
to it by using a combination of IP address and share name, i.e.
"smb:192.168.15.1/Backup Drive".

Hope this helps.

On 8/1/20 10:57 AM, Michael Terry wrote:
> How is this other drive configured? Is it an entry in fstab? And you
> were entering its path as a Local Folder storage location?
>
> If so, we didn't previously do anything special about mounting fstab
> entries for you. But I just added some code to try that.
>
> Could you give a beta build a try and see if it works for you?
> `snap install deja-dup --classic --edge`
>
> ** Changed in: deja-dup
> Status: Triaged => Incomplete
>

[Michael Terry (mterry)]

OK, then yah, I suspect the change I recently made should fix this: deja-dup now checks fstab and mounts the target location before a backup starts.

You should be able to test it by installing the latest edge snap:
snap install deja-dup --classic --edge

[Sebastien Bacher (seb128)]

The upstream commit seems to be https://gitlab.gnome.org/World/deja-dup/-/commit/e349a1c7 , if it fixes the issue we should probably backport that one to the LTS

[William Ritchie (incryptx)]

Yes, since 20.04, I have not had the problem, but I thought it was due
to using a linux server and smb  which solved the problem.

The original problem was localized to my desktop machine and a local
drive, which would fail after bootup because the dedicated backup
drrive/partition was not mounted at bootup. Only after mounting the
drive/partition would the backup run. This prevented the automated
backup that should run shortly after the system booted up. To be clear,
the backup partition and deja-dup were being run locally on a client
machine. Since 20.04, I built a xigmanas server and moved the backup
destination off the local machine to the server and started using smb to
access the backup partition. This saved space on the local machine and
further protected the backups as they are now stored on a remote server.

Thanks for the reply, response and fix.

On 8/2/20 4:13 PM, Michael Terry wrote:
> OK, then yah, I suspect the change I recently made should fix this:
> deja-dup now checks fstab and mounts the target location before a backup
> starts.
>
> You should be able to test it by installing the latest edge snap:
> snap install deja-dup --classic --edge
>

[Launchpad Janitor (janitor)]

This bug was fixed in the package deja-dup - 42.2-1ubuntu1

---------------
deja-dup (42.2-1ubuntu1) groovy; urgency=medium

  * Resynchronize on Debian, remaining change
  * debian/control.in, debian/rules:
    - Suggests python3-pydrive, ideally that would be a recommends but
      the package needs to be promoted first
    - set -Dpydrive_pkgs=python3-pydrive this way deja-dup knows how to
      install the pydrive backend on demand via packagekit
  * debian/patches/disable-google-drive.patch:
    - remove the patch disabling google drive, python3-pydrive is available
      now in focal

 -- Sebastien Bacher <email address hidden> Wed, 19 Aug 2020 16:50:27 +0200