[Solved] DejaDup Not Backing Up, Ascii Error?

Hey everyone,

I’ve never used DejaDup before, but since it’s the default backup utility in Ubuntu Mate, I thought I’d give it a shot. Unfortunately, I can’t get anywhere, because as soon as it starts a backup, it throws this error:

    Traceback (innermost last):
  File "/usr/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1393, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1511, in do_backup
    full_backup(col_stats)
  File "/usr/bin/duplicity", line 572, in full_backup
    globals.backend)
  File "/usr/bin/duplicity", line 454, in write_multivol
    (tdp, dest_filename, vol_num)))
  File "/usr/lib/python2.7/dist-packages/duplicity/asyncscheduler.py", line 146, in schedule_task
    return self.__run_synchronously(fn, params)
  File "/usr/lib/python2.7/dist-packages/duplicity/asyncscheduler.py", line 172, in __run_synchronously
    ret = fn(*params)
  File "/usr/bin/duplicity", line 453, in <lambda>
    vol_num: put(tdp, dest_filename, vol_num),
  File "/usr/bin/duplicity", line 342, in put
    backend.put(tdp, dest_filename)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 395, in inner_retry
    % (n, e.__class__.__name__, util.uexc(e)))
  File "/usr/lib/python2.7/dist-packages/duplicity/util.py", line 79, in uexc
    return ufn(unicode(e).encode('utf-8'))
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 37: ordinal not in range(128)

Now, if I’m reading this right, it looks like it’s trying to read the duplicity python scripts with ascii instead of unicode. Am I correct? If so, how would I rectify that?

Thanks in advance for any insight you can provide. Cheers!


UPDATE:

I did a bit more digging, and found a bug for this on Deja Dup’s launchpad page. It looks like this issue is affecting Ubuntu 18.04. Here’s the link; if you’re experiencing this issue as well, go to the bug report and let them know.

https://bugs.launchpad.net/deja-dup/+bug/1736164


UPDATE 2: FOUND THE ISSUE

The folder I was trying to backup to “/var/backups/james” was owned by root, so DD didn’t have permission to use it. chmod’d it back to my user and now it works like a charm. It was a permissions problem the whole time! Now, why that manifested itself as a unicode error is a total mystery to me. But I’ll go update the bug file so that perhaps they can include a caveat in the code for providing a more informative error message when this is the case.

Using DejaDup with UM 18.04 without any issues. In fact, I’ve never had any issues with DD.

You have duplicity installed, but you problem appears to be that there’s a conflict between locales (language settings) ascii and maybe UTF-8, which Ubuntu uses by default.

Are you running a non-default language?

Have a look here…
https://www.thomas-krenn.com/en/wiki/Configure_Locales_in_Ubuntu

Nope, just plain old en_us.

james@OldDell:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
james@OldDell:~$ cat /etc/default/locale
#  File generated by update-locale
LANG="en_US.UTF-8"

Unless it’s an ascii character in a specific file that it’s choking on? Do you know where I might find duplicity’s log? I can perhaps see, although in the bug report I found and linked to, I saw others complaining that even in duplicity’s most verbose logs it wasn’t giving the filename that was causing the hangup.

If you’re running 18.04, try to uninstall and reinstall both DD and duplicity. Make sure all of your updates are in and delete anything in your ~.cache folder.

DD defaults your home folder as selected file, and you obviously select the backup location.

It should “just work” because it’s *buntu. I’ve never had one single issue with DD over the course of many years and several distros. I’m using a fresh install of 18.04 UM, and it works like a charm.

It’s a strange error, but at least you’re seeing it as a UnicodeDecodeError. If the above doesn’t work, you can try to reinstall anything ascii/unicode, etc. via Synaptic.

GM

1 Like

Ran apt update && upgrade. Marked Deja Dup and Duplicity for complete removal in synaptic. Reinstalled. Deleted contents of ~/.cache. Still having an issue. Searching “ascii” or “unicode” in synaptic doesn’t pull up any packages I would think to be the culprit, just libs or fonts.

Venerable try, any other thoughts? The fact that this is a reported bug over at Deja-Dup’s launchpad gives me hope that I’m not crazy, and this is a real bug that needs to be fixed. Of course, if I can tweak whatever it is I’m doing to get it to work somehow, I’m down for that.

If you run 18.04 live and/or in a virtualbox, can you duplicate the error? In theory, install prior to first updates should behave similar to your live session.

If you can’t duplicate the error this way, then you may consider a reinstall or go with another backup utility. Again, DD is pretty rock solid by now, and especially in the Ubuntu spins. That’s not saying it’s impossible, but maybe more so improbable.

Did you ever have another desktop environment installed besides Mate or tinker/bleachbit/etc with your install which may have drawn in the locale conflict?

1 Like

FOUND THE ISSUE.

The folder I was trying to backup to “/var/backups/james” was owned by root, so DD didn’t have permission to use it. chmod’d it back to my user and now it works like a charm. It was a permissions problem the whole time! Now, why that manifested itself as a unicode error is a total mystery to me. But I’ll go update the bug file so that perhaps they can include a caveat in the code for providing a more informative error message when this is the case.

Thanks GM for your help!

Anytime.

Any of these Ubuntu LTS spins are pretty darn good, especially the longer they’re “burned in”, or as they become “more” stable with time. A simple backup should be a breeze.

You may consider an alternative for your DD backup, maybe just a location within your home folder to avoid those pesky permission problems, etc. within root.

GM