Permission denied: rsync backup from my Fedora box to my DS207+ (DSM 2.3) NAS….

I’ve got a NAS that I’m very happy with; the DS207+ from Synology. I back up my wife’s massive Photoshop and Ilustrator files from her Mac without problems (using Superduper) – however, backing up stuff from my Linux box (Fedora) has turned out to be a little bit more tricky. I might have set up the DS207+ wrongly with respect to the users, groups and privileges from the start (I’ve had the box longer than I’ve had Linux) but regardless of what the reason is the practical problem is that trying to back up to the server – using DejaDup or grsync (can be found in the standard repositories both for Ubuntu and Fedora) – fails with “access permitted” problems.

I’ve tried to rsync using the server’s IP address;

and I’ve tried to use a mount point after adding a cifs mount statement to my fstab file:

// /mnt/ds_jarl cifs credentials=/etc/.ds_credentials,_netdev 0 0

To no avail and still I get problems with rsync throwing up “Permission denied (13)” errors when it tries to create (or delete) directories.

From what I’ve been able to gleam from various fora there seems to be an issue that quite a few people have been struggling with in one form or other. If this is related to a subtle difference in the use of CIFS or Samba I don’t know but the bottom line is that it doesn’t work…for me at least.

Anyway, here be what I did to make this work for me. It might not work for you but hopefully it will give you a possible avenue to try out, should you have problems getting rsync to work with your DS207+.

  • Firstly I followed the instructions here to create an ssh key file. I subsequently copied one into my /home/jarl/.ssh folder (had to create it first) as per instructions. I also copied it over to a new /homes/admin/.ssh folder on the DS207+ (simply using the File Station.) Following that I could ssh in without entering a password BUT as opposed to what the instructions on said web site says I had to specify that I was the “admin” user for this to work. I believe this has something to do with the limitations on who can ssh into the DS207+. In short, the ssh line to log in had to be this:
    • ssh -l admin -i /home/jarl/.ssh/rsync-key
    • NOTE: the use of “-l admin” here!
  • Next I could compose the full rsync command line and instruct it to use ssh (as admin!) to connect to my NAS and do it’s thing:
    • rsync -rv -o -c -z -e ssh -l admin -i /home/jarl/.ssh/rsync-key /home/jarl/
    • NOTE: I composed the whole command line using grsync and just added the -e ssh… part manually

This works fine now, although all the files sync’d up are owned by “admin” of course…

I will try to make this work for the standard user as well; it makes no sense that you should have to be admin to make this work..!

Sorting out Rkhunter on Fedora 13 and hooking it up to Anacron

I’ve used rkhunter (Root Kit Hunter) in the past (on my old Ubuntu machine) and even though it might be a little overtly paranoid it’s not a bad idea to run sometimes and check your system integrity. Now that I’ve recently got a fresh Fedora 13 install I wanted to set up rkhunter again on my clean system.

I installed it with YUM:

# yum install rkhunter

and invoked it to make it update it’s file properties database (basically saying: this system is clean, use it as a reference for future checks)

# rkhunter --propupd

(note: run as root)

And then proceeded to run a check on the system (not really needed, since I just propupd’ it but I just wanted to check to see if things worked):

# rkhunter --check
Invalid XINETD_CONF_PATH configuration option - non-existent pathname specified: /etc/xinetd.conf

(my highlighting)..

Ok, so apparently this is a known problem on Fedora since version 11 and is fixed by commenting out the following line in the /etc/rkhunter.conf file:


Having done that rkhunter runs as expected and checks the system for problems.
Btw, you can get more detailed info on rkhunter here.

Now I wanted to add rkhunter updates and checks to Anacron so that it could be run every couple of days. Since I’m on a laptop that isn’t always on Anacron is the right choice (as opposed to Cron.) More on that can be found here.

To make this work I had to edit the /etc/anacrontab file which lists the different tasks to be run. By default it contains some entries related to cron, there’s some trickery involved between the two, but that’s not relevant to the task at hand. All that was needed was to add the following two lines to the file:

5 5 rkhunter.update rkhunter --update
5 15 rkhunter.check rkhunter --check --sk --rwo

This reads:
No earlier than every 5 days, no earlier than 5 minutes after anacron first starts, a task we identify as “rkhunter.update” is run and the command is “rkhunter –update”…simples.

Similar for the next line, which is the actual rootkit check. (The parameters “–sk” and “–rwo” mean: don’t ask for key presses and only output warnings.)

NOTE: I had to search around a bit before I realized that all the tasks in the anacron (and presumably cron-) -tab files are run as root…

Anacron (and cron) both email the output from these runs to the root account. To see what’s been emailed the simple (but not elegant!) method is this:

cat /var/spool/mail/root

So now you know how to install and run rkhunter on Fedora 13 and to get it set up to run on a regular basis using anacron.