4

I have been using Déjà Dup to create backups for several years. Recently it started to fail with the message

Permission denied when trying to read ‘/duplicity-inc.20161201T072516Z.to.20161202T074205Z.manifest.gpg’.

This seems to happen after the program has written backup files to the very same directory. The ownership of the file and the containing directory seem right:

drwxr-xr-x 2 myuser myuser 68K Dec  2 08:47 dejadup-backup/

-rw-r--r-- 1 myuser myuser 13K Dec  2 08:47 dejadup-backup/duplicity-inc.20161201T072516Z.to.20161202T074205Z.manifest.gpg

The target directory is on a remote server mounted via davfs2. My /etc/fstab looks like this:

$ cat /etc/fstab 
...
# mount the fileserver
https://fileserver.domain /mnt/fileserver davfs user,_netdev,auto,uid=myuser,gid=myuser 0 0

Any ideas what might cause this and how I can fix it?

Fabby
  • 34,341
  • 38
  • 97
  • 191
jotrocken
  • 332
  • 5
  • 16
  • What is the command you're executing and the output of `smartctl --all /dev/XdY` where X and Y are the letters denonimating your disk? – Fabby Jan 04 '17 at 09:58
  • I am mounting a remote filesystem with davfs on startup via /etc/fstab. So I cannot use smartctl to show details. However, I can access that mount without problems. Deja dup is set up using the UI. How can I see the actual commands that it runs in the background? – jotrocken Jan 05 '17 at 15:28
  • 1
    turn the debug level up and look at the log file... ;) – Fabby Jan 05 '17 at 15:32
  • Here it is: [dejadup.log](https://gist.githubusercontent.com/anonymous/a0f25fa709c6da15c846102b18964a2e/raw/8ae547c29e94bc37734f47f1ec95a58ab1f2fdb3/deja-dup.log). The `tmp/` in my home directory goes away right after dejadup finishes. So I cannot inspect that. However, I took a closer look into the file `*.manifest.gpg` and even though it is owned by my user and access rights are `644` I cannot read from the file (not even as sudo). – jotrocken Jan 09 '17 at 08:41
  • 1
    Run `fsck` on the disk and try again. If that doesn't help, try to create a new directory `dejadup-backup2` and use that to make a backup so we can compare the 2 after a successful back-up. – Fabby Jan 09 '17 at 16:56
  • Cannot run `fsck`, because the device is mounted. Cannot create a new directory, even with sudo, because of `Permission denied`. This seems to be a filesystem problem. Will continue later the day... – jotrocken Jan 10 '17 at 08:59
  • what are the permissions of the one-up directory? – Fabby Jan 10 '17 at 09:16
  • Same as for the contained one. – jotrocken Jan 10 '17 at 10:07
  • Did you add ACL? Does it work for the Guest account? – Fabby Jan 10 '17 at 12:54
  • Not that I know. However, there seems to be a problem with the remote server. Now there is enough evidence to convince our OPS that it's not my deja-dup settings and to have a look. I'have updated the original question to reflect that. Although it's not related to the original question, I would not have figured that out without your help. I'd like to award you the bounty if you file an appropriate answer. – jotrocken Jan 10 '17 at 15:59
  • For the reader, this is how to run deja-dup with debug information: `DEJA_DUP_DEBUG=1 deja-dup --backup > dejadup.log 2>&1` – jotrocken Jan 11 '17 at 08:19
  • 1
    Done! :-) Added most important info to your question as this might help some other poor soul in the future. (and +1 to your question as well, as it was an interesting problem) – Fabby Jan 11 '17 at 11:46

2 Answers2

1

For those coming here from a search, I had a similar error, and the problem was that I put / before and after the backup folder name...

Andrew
  • 180
  • 6
1

After debugging was turned on using DEJA_DUP_DEBUG=1 deja-dup --backup > dejadup.log 2>&1, your dejadup.log file contains:

DUPLICITY: ERROR 30 EOFError
DUPLICITY: . Traceback (most recent call last):
DUPLICITY: .   File "/usr/bin/duplicity", line 1532, in <module>
DUPLICITY: .     with_tempdir(main)
DUPLICITY: .   File "/usr/bin/duplicity", line 1526, in with_tempdir
DUPLICITY: .     fn()
DUPLICITY: .   File "/usr/bin/duplicity", line 1380, in main
DUPLICITY: .     do_backup(action)
DUPLICITY: .   File "/usr/bin/duplicity", line 1454, in do_backup
DUPLICITY: .     globals.gpg_profile.passphrase = get_passphrase(1, action)
DUPLICITY: .   File "/usr/bin/duplicity", line 198, in get_passphrase
DUPLICITY: .     pass1 = getpass_safe(_("GnuPG passphrase for decryption:") + " ")
DUPLICITY: .   File "/usr/bin/duplicity", line 93, in getpass_safe
DUPLICITY: .     return getpass.getpass(message)
DUPLICITY: .   File "/usr/lib/python2.7/getpass.py", line 83, in unix_getpass
DUPLICITY: .     passwd = fallback_getpass(prompt, stream)
DUPLICITY: .   File "/usr/lib/python2.7/getpass.py", line 118, in fallback_getpass
DUPLICITY: .     return _raw_input(prompt, stream)
DUPLICITY: .   File "/usr/lib/python2.7/getpass.py", line 135, in _raw_input
DUPLICITY: .     raise EOFError
DUPLICITY: . EOFError
DUPLICITY: .

and a bit further:

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 365, in inner_retry
DUPLICITY: .     return fn(self, *args)
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 563, in get
DUPLICITY: .     self.backend._get(remote_filename, local_path)
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 146, in _get
DUPLICITY: .     self.__copy_file(source_file, target_file)
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 119, in __copy_file
DUPLICITY: .     None, self.__copy_progress, None)
DUPLICITY: .  Error: g-io-error-quark: Error opening file: Operation not permitted (14)
DUPLICITY: . 

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 1 failed. Error: g-io-error-quark: Error opening file: Operation not permitted (14)

So the error must be on the davfs side and you should investigate the server as locally there is nothing wrong at all.

Fabby
  • 34,341
  • 38
  • 97
  • 191