Thats a major problem with using something like Foxpro or Access. Those products are not really suitable for critical applications in an "enterprise" environment. Your users MUST have read/write access to the share for your users to be allowed to update the data. That's why you need a database product designed for a multi-user/network environment. As stated by itsp1965, the "best" you can do, if you can't migrate to MySQL, Sqlserver, oracle or something, is to control access through windows usergroups and hope none of your authorized users do something like accidentally delete your dbf file. Another big problem we have encountered with similar MS Access "databases" is users trying to create shortcuts to the original database but instead making copies of the database on their local machine. You then end up with multiple copies of the db scattered around the office being updated by different users, and you dont notice it until somebody figures out that data is missing from the master copy. You then spend a few days ferreting out the duplicate copies and trying to clean up the data.
I havn't seen foxpro in a long time, but if its anything like MS Access, and if you have the source code for your foxpro database its not too hard to modify your application to serve as a "front end" application and "connect" the application to a "Back end" sql server database of some kind. Then you give your users read access to the application share and you dont need a share for your data, you just connect to it from inside your application.
The bottom line from a security standpoint is that in order for your users to use the application they have to be granted a level of access to the share that would also enable them to cause a lot of problems, and there's not really any way around it that I know of.