When you said "users" I automatically assumed Windows. The only Linux users I routinely deal with are other administrators.
chmod 1740 /chown back_up_admin:individuals_group

I tried that.

What was the result?

Users still had full r-w permissions to their respective $HOME.

Their $HOME directory in their archive partition?
Did the file permissions change at all?
And your setting the chmod recursively? chmod -R 1740 ?
I'm sorry, Woodsman as I look back at my suggestion I didn't think to mention that that changing the directory to "read only" but leaving the files "rw" means the group user can't delete the directory however they can modify the files. I'm sorry to have created this confusion...

Try it with the -R switch and see if that doesn't fix it.

Woodsman, I think you probably already know this but I'll post it just in case somebody finds it informative.

chmod takes a four digit code. The first digit sets the file mode, "sticky" or " owner delete only" is a 1. If your not setting the sticky bit, you don't need to worry about the first digit, the machine automatically populates it with a 0.
The next three correspond to "owner" "group" and "other" respectively. The number is arrived at as follows.
4 allows read
2 Allows write
1 Allows execute.
But the machine adds the numbers together to arrive at the file permission.
So the corresponding code for owner=rwx , group=rw and other=r is 764 or chmod 764 <file or directory name.>
7 = (Read=4) + (Write=2) + (Execute= 1)
6 = (Read=4) + (Write=2)
4 = (Read=4)
Two switches you need to look at in "man chmod".
Recursive or -R, use this carefully because recursive means...recursive, it'll go until it runs out of files and directories on the system branch it's running on. Anything further down the branch that relies on specific file permissions is going to get smoked.
The second is -c, if you use this switch, it outputs the actual permission changes. A good rule of thumb when working on a production server is to output all your permission changes into a file (mines called "permlog") so I always use the -c switch and then immediately "cat" permlog to make sure I didn't screw it up.

1 members found this post helpful.

So "chmod 1740" is the same as "chmod a+t,o=rwx,g=r,o="

The info page mentioned by the man page goes into pretty good detail.

Exactly Richard, but you see how much easier (once you know the trick) and "cleaner" the numeric is type or read, especially if you're going to script it, which is why I always use the numeric, I've just found it to be a good habit to develop and maintain.
I'm a huge fan of the man and info pages. I go back to them over and over, when Woodsman said chmod 1760 didn't work, I freaked out a little and blasted "man chmod" into the terminal, just to make sure the ol' Alzheimers wasn't kicking in (shoulda been 1740 but at the time I didn't understand his goal here very well).

Different strokes for different folks, but I personally find the symbolic version easier to remember and to read than the numeric one. (Especially since the symbolic version matches "ls -l" output.)

Of course, when you use the numbers, you'll never fat-finger an "=" for a "+".

I did not write that the command did not work. I wrote that I tried the command and the result was each $USER still had full r-w access to the backup $HOME/$USER files.

The link shared by NeoMetal in post #14 sheds light on the problem. That the rsnapshot developers address the problem of accessing the backup files indicates the problem I am trying to resolve is not as easy as one would think.

Thank you for sharing the information about chmod. I am not a sysadmin and don't need to memorize the fourth bit for daily usage, but I have known about the fourth bit for many years and occasionally use them in administering my own systems.

I wont bother you anymore about it, Woodsman.
Good luck with that local backup problem.

Thank you for trying to help.

I think the idea with the NFS share is to export it locally - share back on 127.0.0.1 not requiring it to actually pull over the network, would just need nfsd running