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/