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@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
