This is one of those "I'd need to be there with you debugging it" sort of problems, especially since you haven't said which proprietary client you're using.
The answer to your question as asked is "yes and no"; if your NFS mount is /nfs/, and a program interacts with /nfs/foo, that's a normal file as far as that program can tell, period. Unless it asks. If it actually specifically asks the OS "What sort of filesystem is /nfs/foo a part of?", it'll get told that it's NFS. You can't change either of these things, basically; in particular, you can't get the OS to tell the client that the NFS mount isn't an NFS mount, at least as far as I know.
However, it's very unlikely that the client is actually asking.
Here's what I'd check:
- The most likely issue is that the client is running against / (the root file system) and is refusing to cross file system boundaries; that's fairly typical. Again, you can't fix that directly, but what you can probably do is give it other places to look. Try adding your NFS or SMB shares to the client as backup locations explicitly.
- NFS at least (and I think SMB) by default prevents root on a client host from doing a lot of things; if #1 doesn't work, try adding no_root_squash to your NFS exports (make sure it worked by running "exportfs -v" on the master and looking for the option) and see if that helps.
- If those both fail, I would strace the client (using -ff -o /tmp/strace.out or so) and grep for one of the filesystems it's not picking up, and see what errors it's getting, or if it's even trying. If it's not even trying and you've explicitly listed that FS as something to backup, you'd best talk to the vendor.
-Robin
ln -s /path/to/hdd /path/to/new/symlinkOr maybe make a custom script that scrubs the folders to a tmp local folder, backs it up, and deletes...? (although that creates a lot of overhead) – nerdwaller Nov 15 '12 at 17:38