I can't get FUSE to actually mount an NTFS image without root privileges :(

Got that one sorted out.

Normally FUSE allows only the mounting user to access the mounted filesystem. Allowing everybody to access the filesystem would open door to some security issues. Just in case you know what you are doing FUSE provides allow_other mount option that you can use to override the default mode. Since security is in question using allow_other is allowed only to root or root can set it in fuse.conf to allow non-root users to use it.

For some reason the front end program to ntfs-3g sets allow_other by default and, as far as I can tell, doesn't provide any way to not set it.

I patched the ntfs-3g binary so that the option isn't set and now I can mount NTFS images without root privileges.

Quite a few distros install FUSE and ntfs-3g by default so this could still be an option.

Wait what? I thought you were running the version you downloaded from here. If you compiled it yourself you can compile any version, including the latest recommended.

And if you can compile it yourself you can simply hardcode BOINC to report 10 PB of free disk space... (get_filesystem_info(), at the end of lib/filesys.cpp)

Initially, I was misinformed. BOINC has not been compiled on the cluster. This is the regular version.

Wait what? I thought you were running the version you downloaded from here. If you compiled it yourself you can compile any version, including the latest recommended.

And if you can compile it yourself you can simply hardcode BOINC to report 10 PB of free disk space... (get_filesystem_info(), at the end of lib/filesys.cpp)

Initially, I was misinformed. BOINC has not been compiled on the cluster. This is the regular version.

I see, thanks for clarifying that. Erm... That raises the question is there something else that's different from what you have told us (no offense intended.)

Could you run these two commands:

stat -c "%m" /path/to/boincdata/client_state.xml
stat -f /path/to/boincdata/client_state.xml

Hello! :-)

Could you run these two commands:

stat -c "%m" /path/to/boincdata/client_state.xml
stat -f /path/to/boincdata/client_state.xml

Output from host that run BOINC:

-sh-4.1$ stat -c "%m" client_state.xml
?
-sh-4.1$ stat -f client_state.xml
File: "client_state.xml"
ID: 0 Namelen: 255 Type: nfs
Block size: 16384 Fundamental block size: 16384
Blocks: Total: 393216 Free: 4775 Available: 4775
Inodes: Total: 21387593 Free: 21332666
-sh-4.1$

Strange... Total Blocks * Block size = 6G but real volume size is terabytes...

-sh-4.1$ stat -c "%m" client_state.xml
?

Bummer, your stat is too old to know about %m. That command was supposed to tell the mountpoint for the filesystem that contains BOINC's data directory - is it /home2 or something else. You could dig that from output of mount or from /proc/mounts, picking the one that's closest to /path/to/boincdata or run the following commands:

cd /path/to/boincdata
while ! mountpoint `pwd`; do cd ..; done

-sh-4.1$ stat -f client_state.xml
File: "client_state.xml"
ID: 0 Namelen: 255 Type: nfs
Block size: 16384 Fundamental block size: 16384
Blocks: Total: 393216 Free: 4775 Available: 4775
Inodes: Total: 21387593 Free: 21332666
-sh-4.1$

Strange... Total Blocks * Block size = 6G but real volume size is terabytes...

Well, that does tell one thing: BOINC wasn't lying when it told you it was running on 6GB filesystem. At least not more than OS...

Back in February I peeked into source code of both df and stat to see if they do anything different from what BOINC does. I'm not sure anymore but I think df and stat fetched the filesystem details in essentially the same way.

Juha, yes, it is "unexpected behavior" of OS on this computing system.
Thank you!

Not sure if that means case closed, but glad I could be of help.