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:
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.
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.
[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.
Of course. That’s how UNIX links work.
Sorry but can’t help with your Synology issues.
I’ve got a QNAP
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 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”.
