Gary F Mitchell, Computing Facilities Group, 09-OCT-1996
This document describes a problem in the use of PC-NFS by several users to update information in shared files. The problem occurs when the all users who modify a shared file do not all have the same principal group ID. A solution is proposed based on a unix script which is invoked automatically at regular intervals.
There is problem when files are modified or replaced if users do so via PC-NFS. A more lenghthy discussion of how it occurs and what can be done to fix it is available but in summary it is capable of being solved by automatic procedure running on the unix machine periodically.
Users go through an authentication process (usually when the PC is booted, otherwise when a network drive is connected) which associates a unix account with any future PC file transactions.Each user account is associated with a numeric userid and at least one groupid. The userid will usually be unique. The group id will be the same for several users. Such users usually all have some aspect in common and at the ING this is usually taken to be the department such as "Computing Facilities Group" or "Instrument Software Systems" or "Finance" or "Personnel" or "Management". A user has one primary group id but he can also be the member of other groups. Such other groups are his "secondary groups".
Example
| username | primary group | secondary group(s) |
| gfm | computing | managem, root |
| cwmj | electronics | managem |
| pctr | instrums | managem |
Consider the case where we have the fictitious directory slb-info/cfgnews where members of the Computing Facilities Group post news items.If gfm creates a file "shutdown.htm" it aquires the userid of gfm and the group id of the CFG viz "computing". When user pgs attempts to update the file he can because his group id "computing" matches that of the file and group access is set to rwx (read, write, execute). The new file aquires the userid of pgs and the group id of "computing". The result is that all CFG members can access the file
Consider the case of a management group meeting. The action list is held in /slb-info/managem directory in file act1225.htm. Each of the section leaders has to update the file when the actions are completed. If gfm creates the file it aquires the userid of gfm and the group id of "computin". When cwmj attempts to update the file he can not because only group members may modify the file and although the directory /slb-info/managem has group ownership managem the file act1225.htm does not.
Of course there is a solution to this when a user makes a file in a directory slb-info/xxx he should ensure that the file is given the group ownership of that directory. This informationabout what the group ID should be will always be available in the aaareadme.htm file but the process of doing so in PC-NFS is tedious. At this point I suggest you look at PC-NFS Help
Example in Windows95 of getting to PC-NFS help
The instructions are correct - but when in the instructions it says "File Manager" it is talking about the Windows 3.11 file manager program and not about the windows95 file manager program (Explorer). The Windows 3.11 file manager program is still available in windows 95 - to start it use Start -> Run -> Open C:\WINDOWS\Winfile.exe.
You can use this technique desribed in PC-NFS help to correct group ownership but it is tricky. If you change the group ownership of the file to a secondary group(eg gfm changes group ownership to managem) then this cannot be reversed - even if you are the owner of the file unless there is group write access.
It is proposed therefor that a second mecahnism be put in place. A crontab run by system will at regular intervals (every 3 hours?) examine directories in the slb-info tree and correct ownerships, group ownerships and file access permissions. Here is an example C-shell script.