Backup fails if backup destination is not mounted

Bug #1761216 reported by William Ritchie on 2018-04-04
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Déjà Dup
Wishlist
Unassigned
deja-dup (Ubuntu)
Wishlist
Unassigned

Bug Description

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.

Colin Watson (cjwatson) on 2018-04-04
affects: launchpad → ubuntu
William Ritchie (incryptx) wrote :

This was on 18.04 Beta.

William Ritchie (incryptx) wrote :

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.

Paul White (paulw2u) on 2018-04-08
tags: added: bionic
Paul White (paulw2u) on 2018-05-22
affects: ubuntu → deja-dup (Ubuntu)
Launchpad Janitor (janitor) wrote :

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

Changed in deja-dup (Ubuntu):
status: New → Confirmed
Vej (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.

Changed in deja-dup:
status: New → Confirmed
Vej (vej) on 2018-09-16
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

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
>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers