Hi,

for the sake of completeness (though Adam has already made the point: it helps
to understand what you are asked to do rather than blindly doing it - people
make mistakes when giving advice, as the OP has proven ;-):

Akibu Flash wrote on 2015-02-19 13:32:14 -0800 [Re: [BackupPC-users] 
BackupPC-4.0.0alpha3 - Can't create a test hardlink between a file...]:
> [...]
> Once I fixed the permissions issue, the command start stop command would
> work and give me an "ok."  

Beware!

*When starting daemons*, the invoking process can only detect errors the
daemon encounters *before* forking into the background. Often enough and not
necessarily in the context of BackupPC, I've seen the "ok" type success
message only to find out that the daemon had terminated immediately after
forking, sometimes due to the inability to open a log file, meaning there's
absolutely no trace of why the daemon was not running. This can be extremely
annoying to debug.

BackupPC does some tests before forking, but there are several fatal errors
that can happen after forking. In particular, the log file is opened after
forking, and this *can* fail (e.g. permission problems), so BackupPC *can*
potentially silently die after you get the "ok".

What this means is: "I got 'ok', so it's running" makes no sense for daemon
processes. It's "I can see it in 'ps', so it's running". "Ok" only means it
didn't fail for the more obvious reasons, or rather, not for those of the more
obvious reasons that could be tested beforehand :-).

> [...]
> backuppc@linux-pc5:/$ ls -ld /data
> drwxrwx---+ 3 root root 4096 Jan 18 23:00 /data

This is actually interesting. ACLs? SElinux? I'm referring to the "+" at the
end of "drwxrwx---+". It might even be important, assuming your backuppc user
is *not* in the root group!?

More explicitly: these permissions seem strange to me, but I suppose someone
set them up this way (your distribution? your distribution's BackupPC
package?). Without the whole picture (ACLs, effective UID, GID and
supplementary groups of the running BackupPC process) I can't say whether
this will work or not, though if it didn't, BackupPC should fail before you
get the "ok" message, meaning you wouldn't get the "ok" message.

I'd normally have expected something like

> drwxr-xr-x 3 root root 4096 Jan 18 23:00 /data

Access to sensitive information below /data can be limited by subdirectory.
I don't see the point in hiding the subdirectories altogether.

> backuppc@linux-pc5:/$ ls -ld /data/BackupPC
> drwxrwx---+ 5 backuppc backuppc 4096 Jan 18 23:00 /data/BackupPC

Except for the "+", that is what I'd expect here.

> [...]
> backuppc@linux-pc5:/$ tune2fs -l /dev/mapper/dreux-root
> tune2fs 1.42.12 (29-Aug-2014)
> tune2fs: Permission denied while trying to open /dev/mapper/dreux-root
> Couldn't find valid filesystem superblock.
> 
> Is the output what was to be expected?

Yes. This is the "understanding what you're doing" part again. As non-root
user, you don't have permission to access the device file. The error message
is not "Couldn't find ...", it's "tune2fs: Permission denied ...", and it's
quite clear :-). "Couldn't find ..." is tune2fs's explanation why it gave up
as a result of not being allowed to read from the device.

If you want meaningful output, you'll need to run the tune2fs command as
root. And *before* you do, you might as well try

        backuppc@linux-pc5:/$ df -T /data/BackupPC

and see if the type of the file system is really one of ext2, ext3, ext4;
otherwise 'tune2fs' is simply the wrong tool. All of that said, I'm not sure
why the OP wanted you to run tune2fs. Perhaps he wanted to see whether it
really is an ext[234] file system :-).

On a side note, if you're serious about running BackupPC, you definitely
*don't* want to have the pool on your root file system. For testing,
evaluation, and perhaps even debugging problems, you might be fine, but for
production use, you are asking for problems. You're apparently using LVM,
so creating an independent logical volume is really easy (presuming you
haven't allocated all of the space to your root FS).

> Or should my merely removing the linked target also remove the linked file?

No, that will never happen.

I hope some of that helps rather than confuses ...

Regards,
Holger

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/