Amanda and backup user permissions on NAS mount points

Hello, I am having permissions issues for the backup user in trying to setup Amanda, running out of ideas, and suspect I am missing something obvious.

I have a mount point on a Synology NAS server mounted as /mnt/backups. This is the root of several backup directories on the NAS, one of which is for the OpenHAB Pi.

The openhabian user can access the directory tree just fine, but the backup user cannot. I am guessing that ‘backup’ needs to be added in /etc/sudoers.d ??
Setting permissions and owners doesn’t matter.

[15:48:10] openhabian@openHABianPi:~$ ls /mnt/backups/openhab/
amanda-backups  slots
[15:48:18] openhabian@openHABianPi:~$ ls /mnt/backups/openhab//slots
drive0  drive1  slot1  slot10  slot11  slot12  slot13  slot14  slot15  slot2  slot3  slot4  slot5  slot6  slot7  slot8  slot9  slots
[15:48:22] openhabian@openHABianPi:~$
[15:48:50] openhabian@openHABianPi:~$
[15:48:51] openhabian@openHABianPi:~$ pwd
/home/openhabian
[15:48:55] openhabian@openHABianPi:~$ sudo su backup
[15:49:05] backup@openHABianPi:/home/openhabian$ amcheck openhab-dir
Amanda Tape Server Host Check
-----------------------------
ERROR: directory '/mnt/backups/openhab/slots' does not exist
NOTE: host info dir /var/lib/amanda/openhab-dir/curinfo/openHABianPi does not exist
NOTE: it will be created on the next run.
NOTE: index dir /var/lib/amanda/openhab-dir/index/openHABianPi does not exist
NOTE: it will be created on the next run.
Server check took 0.577 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 3.397 seconds.  0 problems found.

(brought to you by Amanda 3.3.9)
[15:49:14] backup@openHABianPi:/home/openhabian$ ls /mnt/backups
ls: cannot open directory '/mnt/backups': Permission denied
[15:49:32] backup@openHABianPi:/home/openhabian$ ls -l /mnt
total 0
d--------- 1 backup backup 200 Jun 29 14:39 backups
[15:49:48] backup@openHABianPi:/home/openhabian$ exit
exit
[15:50:03] openhabian@openHABianPi:~$ ls -l /mnt
total 0
drwxrwxrwx 1 backup backup 200 Jun 29 14:39 backups
[15:50:07] openhabian@openHABianPi:~$

Obviously the openhabian user has rights that the backup user doesn’t. Or perhaps the mount is missing options. Here is the line from /etc/fstab:

10.56.58.20:/volume1/backup     /mnt/backups    nfs     defaults

Ironically, the Amanda install successfully created all the slots directories and such. Of course that was run from the openhabian user sudo’ing into the config utility, so of course it worked.

Suggestions welcomed.

No, sudo has nothing to do with permissions which are your problem.

Do groups as user backup and ls -la /mnt as root. I suspect /mnt has permissions that exclude user backup. If I was to guess, it’s group-owned by a group that openhabian is in but backup is not.

So effectively it ran as root.

Thanks for the feedback. Output as requested:

[14:52:35] backup@openHABianPi:/home/openhabian$ ls -la /mnt
total 8
drwxr-xr-x  3 root   root   4096 Jun 29 15:47 .
drwxr-xr-x 22 root   root   4096 Jun 29 15:24 ..
drwxrwxrwx  1 backup backup  200 Jun 29 14:39 backups
[14:53:59] backup@openHABianPi:/home/openhabian$ groups
backup disk tape
[14:54:19] backup@openHABianPi:/home/openhabian$ exit
exit
[14:54:30] openhabian@openHABianPi:~$ ls -la /mnt
total 8
drwxr-xr-x  3 root   root   4096 Jun 29 15:47 .
drwxr-xr-x 22 root   root   4096 Jun 29 15:24 ..
drwxrwxrwx  1 backup backup  200 Jun 29 14:39 backups
[14:54:33] openhabian@openHABianPi:~$

Widened the NFS permissions on the Synology server and got past that, but now it can’t create a symlink for drive2 (symlinks for drive0 and drive1 are invalid as I moved the mount point from /home/openhabian to /mnt.)

Tried removing the amanda packages and reinstalling and seem to have made matters worse - whole slew of chown errors trying to setup the slots directories and symlinks. Viz:

2019-06-30_15:54:58_PDT [openHABian] Setting up the Amanda backup system ...
$ apt -y install amanda-common amanda-server amanda-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
amanda-client is already the newest version (1:3.3.9-5).
amanda-common is already the newest version (1:3.3.9-5).
amanda-server is already the newest version (1:3.3.9-5).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
/bin/chown: changing ownership of '/mnt/backups/openhab/slots/drive0': Operation not permitted
/bin/chown: changing ownership of '/mnt/backups/openhab/slots/drive1': Operation not permitted
/bin/chown: changing ownership of '/mnt/backups/openhab/slots/slots': Operation not permitted
/bin/chown: changing ownership of '/mnt/backups/openhab/slots': Operation not permitted
/bin/chown: changing ownership of '/mnt/backups/openhab/amanda-backups/amanda_data_20190630020001.tar.gz': Operation not permitted
/bin/chown: changing ownership of '/mnt/backups/openhab/amanda-backups': Operation not permitted
/bin/chown: changing ownership of '/mnt/backups/openhab': Operation not permitted
/bin/chmod: changing permissions of '/mnt/backups/openhab': Operation not permitted
/bin/chmod: changing permissions of '/mnt/backups/openhab/slots': Operation not permitted
/bin/chmod: changing permissions of '/mnt/backups/openhab/amanda-backups': Operation not permitted
/bin/chmod: changing permissions of '/mnt/backups/openhab/amanda-backups/amanda_data_20190630020001.tar.gz': Operation not permitted
mkdir: cannot create directory ‘/mnt/backups/openhab/slots’: File exists
/bin/chown: changing ownership of '/mnt/backups/openhab/slots': Operation not permitted
ln: failed to create symbolic link '/mnt/backups/openhab/slots/drive0/slots': File exists
ln: failed to create symbolic link '/mnt/backups/openhab/slots/drive1/slots': File exists
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot1’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot1': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot2’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot2': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot3’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot3': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot4’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot4': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot5’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot5': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot6’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot6': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot7’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot7': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot8’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot8': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot9’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot9': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot10’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot10': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot11’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot11': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot12’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot12': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot13’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot13': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot14’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot14': No such file or directory
mkdir: cannot create directory ‘/mnt/backups/openhab/slots/slot15’: Permission denied
chown: cannot access '/mnt/backups/openhab/slots/slot15': No such file or directory
chown: changing ownership of '/mnt/backups/openhab/amanda-backups': Operation not permitted

As these commands run as root they woukd work.
I vaguely recall there’s a NFS option to map root to some unauthorized user on the NFS server, I guess you enabled that (wrongly so).

Synology exposes various mapping options for other-than-root users. If I leave it with no mapping, then the amanda install succeeds. However, the backup (or amanda) user is then unable to read any of the directories on the NAS under the mount point when amcheck is run. If I map all users to “admin” (Synology’s pseudo-root user) then it can at least traverse the directory tree, but then fails to create the symlink for driveN. So, amcheck fails - permission denied. Since symlinks don’t really reside in the directory they are shown, it seems backup or amanda needs write access to where they really live?

viz:

[18:25:47] backup@openHABianPi:/home/openhabian$ amcheck openhab-dir
Amanda Tape Server Host Check
-----------------------------
slot ?: Can't make directory '/mnt/backups/openhab/slots/drive2': Permission denied
ERROR: Can't make directory '/mnt/backups/openhab/slots/drive2': Permission denied
NOTE: host info dir /var/lib/amanda/openhab-dir/curinfo/openHABianPi does not exist
NOTE: it will be created on the next run.
NOTE: index dir /var/lib/amanda/openhab-dir/index/openHABianPi does not exist
NOTE: it will be created on the next run.
Server check took 0.676 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 2.648 seconds.  0 problems found.

(brought to you by Amanda 3.3.9)

BTW, today’s install of amanda has a duplicate specification of dumptype amraw in the generated amanda.conf file. I suspect the second one is supposed to be comp_amraw as it has the compress fast option specified.

There is also an issue with the conf if one tries to enable raw SD card dumps. The disklist ends up referring to a dumptype amcheck doesn’t understand.

Sorry to be so dense.

Of course. That’s how UNIX links work.
Sorry but can’t help with your Synology issues.
I’ve got a QNAP :wink:
I used to have a similar issue when enabling “extended folder access rights” or similar.

Yes, the tapetype in amanda.conf (and disklist) needs to be named comp-amraw. Will be fixed asap but you can edit manually.

Sorry to dig this up but I ran into the exact same problem with my Synology NAS trying to set up amanda using an NFS share. Did you find a solution in the meantime?

What I found was that you need two different settings for setup and running the backup. The first setting for setup is to use No Mapping in the NFS settings of the synology NAS. In order to run the backup I had to change this setting to “Assign root to admin”.

I am still not sure whether this is really the solution as I have not tested the backup yet. However, at least it allows me to even run the backup procedure

I never did sort it out.

I have all my items, things, rules, etc. on cloud storage, and that’s the stuff to me that’s important to back up. Using Visual Studio Code to edit them it’s convenient to use OneDrive and then the Pi just pulls the updated files anyway.

So, the backup “strategy” is in the event of disaster, just rebuild the Pi with OpenHabian and layer on the saved pieces from the cloud.

It’s about the right time to reconsider that. See the new auto-backup feature in openHABian. It keeps your backup SD ready for use AND does an Amanda backup to local SD.
You can do that in addition to your cloud backup and I wouldn’t rely on the cloud alone. Too many things that can go wrong when you’re in need of a restore, and the cloud is, as Kai has put it once “just other people’s computers”.

For me the solution I mentioned above works. I have put everything together for someone else who might run into the same issue:

Setup Amanda for a Synology NAS

  • Setup an NFS share on Synology (without encryption!)
  • Configure the NFS Settings in Synology to “No mapping” (or however it is translated in your local lang)
  • Start the Amanda Setup from the openhab-config
  • Wait for everything to finish, then
  • Switch the nfs settings in the synology to “Assign root to admin”

Test the backup with

sudo su - backup
amcheck openhab-dir

Run it with

amdump openhab-dir

I had to run amdump twice (first time ended with an error message I do not recall atm). The second time it went through and from then on it worked