JPH086839A - Distributed file system - Google Patents

Abstract

PURPOSE:To grant the authority of amounting request, given only to a privileged user in the NFS (distributed file system) because of the security, even to a general user while holding the security. CONSTITUTION:A mounting right confirming means 21 refers to a password file 23 and a share management file 24 and confirms whether or not a server 20 has the right to mount. A share execution means 22 allows sharing when the right to mount is given. A mounting right confirming means 12 confirms whether or not a client 10 has the right to mount and writes information showing that mounting by a mounting means 13 is successful to a mounting state description file 17 when the mounting is successful. A mounting resetting right confirming means 15 refers to the mounting state description file 17 and confirms whether or not there is the right to reset moldnting. A mounting resetting means 16 resets the mounting.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a distributed processing system in which a plurality of computers are connected by a network, and is particularly adopted for sharing disk resources (files provided on the disk resources) owned by each computer. Distributed file system. The distributed file system of the present invention is premised on being realized by a distributed processing system adopting the UNIX operating system (“UNIX operating system”).
Is UNIX System Laboratories
s, Inc. Developed and licensed by).

[0002]

2. Description of the Related Art A UNIX operating system is a distributed file system that realizes a function of sharing and distributing disk resources on a network.
RFS (Remote File System) and NFS (Network File System)
Etc. are provided. These distributed file systems are technologies for making disk resources distributed on the network appear to be local disk resources in each computer. The distributed file system of the present invention is
Of these, it is assumed that it will be applied to the environment where NFS can be used.

In the conventional distributed file system (NFS), for security reasons, the following restrictions (1) and (2) have been set when executing remote mount (NFS mount). In the following description, the server means a remote mount destination computer, and the client means a remote mount source computer. Further, in the following description, the remote mount (in the present invention, the NFS mount) is simply expressed as “mount”.

As a precondition for mounting, it is necessary to share (share, mount permission) a mount point (directory related to mounting) on the server side. Here, the user who can specify the share for the mount point is limited to the privileged user of the server regardless of the directory of the mount point.

The client issues a command requesting a mount request, and the client issues a mount request to the server based on the command. Here, the command can be issued only to the privileged user of the client.

On the other hand, due to the development and popularization of the UNIX operating system (including the development and popularization of electronic computers to which the UNIX operating system is applied), one general user (user other than privileged user) has an account (password) for a plurality of computers. Registration of the general user in the file) has become common, and the personal disk resources of general users are often distributed to multiple computers. Therefore, even general users are more likely to want to mount their own disk resources in other computers.

However, due to the existence of the above restrictions,
Unless a general user becomes a privileged user of both a server and a client, he / she cannot freely mount a disk resource on another computer even with his / her own disk resource.

[0008]

In the above-mentioned conventional distributed file system, a general user cannot freely mount a disk resource in another computer even if the user owns the disk resource. There has been a problem that the convenience and work efficiency of the general user are deteriorated. That is, specifically,
There was a problem as shown in.

It is difficult to transfer personal disk resources in a network.

Once mounted, the disk resources of another computer on the network can be used without logging in to the other computer on the network. However, conventionally, such convenience cannot be enjoyed.

Since personal disk resources cannot be distributed and held, each general user needs to have the same file in each computer, which results in waste of disk resources in the entire distributed processing system.

[0012] On the other hand, there is a drawback in that the mount is allowed to the general user without limitation, and a problem occurs from the viewpoint of security.

In view of the above points, an object of the present invention is to allow a general user to freely mount a personal disk resource of the general user on another computer while maintaining security (the disk. It is to provide a distributed file system that facilitates access to files on resources.

That is, an object of the present invention is to provide a distributed file system which makes it possible to give a general user other than a privileged user the authority of a mount request, which was given only to the privileged user for security reasons in NFS. To provide.

The prior art of the distributed file system related to the UNIX operating system is disclosed in Japanese Patent Application Laid-Open No. 63-201864 (Distributed Data Processing System) and Japanese Patent Application Laid-Open No. 1-287756 (Activation of Distributed File). Method) ”has been published.
However, these conventional techniques are techniques for eliminating deadlock (Japanese Patent Application Laid-Open No. 63-201864) and facilitating file startup (Japanese Patent Application Laid-Open No. 1-287756), and while maintaining security. The configuration and the like are different from those of the present invention intended to enable mounting by a general user (here, it means the NFS mount as described above).

[0016]

DISCLOSURE OF THE INVENTION A distributed file system of the present invention is, in a distributed processing system in an environment where NFS can be used, a server-side password file for managing an account of a general user who owns disk resources on the server side, A server-side share management file that is provided for each general user and that manages information about shares for the general user, and a client-side mount status description file that holds information indicating the mount status for each general user, The present invention relates to a client side mount request issuing means for issuing a server side mount request based on a general user mount request command, and a server side mount request issued by the mount request issuing means with reference to the password file and the share management file. On the server side The server side mount right confirmation means that issues the share request when the presence or absence of the mount right is confirmed, and the share request is issued based on the share request issued by this server side mount right confirmation means. A server-side share execution unit that executes the execution, and a client-side mount request issued by the server-side mount right confirmation unit after successful execution of the share by the share execution unit, and a client side related to the client-side mount request If the mount right is confirmed, the mount execution request is issued when it is determined that the mount right is present, and when the mount execution based on the mount execution request is successful, the information indicating that is displayed is the mount status description. Mount right confirmation means on the client side that writes to a file and this client side And client-side mount execution means for performing the execution of the mount on the basis of the issued mounted execution request by mounting right confirmation means,
Unmount request issuing means on the client side that issues an unmount request based on a general user unmount request command, and unmount relating to the unmount request issued by the unmount request issuing means by referring to the mount status description file Check for the right,
Unmount right confirmation means on the client side that issues an unmount execution request when it is determined that there is unmount authority, and a client that releases the mount based on the unmount execution request issued by this unmount right confirmation means Side unmounting means.

[0017]

In the distributed file system of the present invention, the password file manages the account of the general user who owns the disk resource on the server side, and the share management file provided for each general user relates to the share for the general user. It manages information, the mount status description file holds information indicating the mount status for each general user, and the mount request issuing means issues a mount request on the server side based on the general user mount request command, and confirms the mount right on the server side. The means refers to the password file and the share management file to check the presence or absence of the mount right on the server regarding the server side mount request issued by the mount request issuing means, and issues a share request when it is determined that there is mount right. , Share execution means is mounted on the server side The share is executed based on the share request issued by the confirming means, and the mount right confirming means on the client side issues the mount on the client side issued from the mount right confirming means on the server side after the share executing means succeeds in executing the share. When a request is received and the client side mount request is checked for the mount right on the client side and it is determined that there is mount right, a mount execution request is issued and if the mount execution based on the mount execution request is successful The information indicating that is written to the mount status description file, the mount execution means executes the mount based on the mount execution request issued by the mount right confirmation means on the client side, and the mount release request issuing means releases the general user mount. Mount solution based on request command Issued the request,
The unmounting right confirmation means refers to the mount status description file to check whether or not there is the unmounting right related to the unmounting request issued by the unmounting request issuing means. Issued and the mount release means releases the mount based on the mount release execution request issued by the mount release right confirmation means.

[0018]

The present invention will be described in detail with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of an embodiment of the distributed file system of the present invention.

The distributed file system of this embodiment includes a plurality of computers (including a client 10 and a server 20).
Are implemented in a distributed processing system (distributed processing system adopting UNIX operating system) connected by a network, and the client 10
And a server 20. It should be noted that any computer (computer having disk resources) connected to the network can be the client 10 or the server 20.

The client 10 has a mount request issuing means 11, a mount right confirming means 12, a mount executing means 13, a mount release request issuing means 14, a mount release right confirming means 15, a mount releasing means 16, and a mount. Situation description file 17 (/tmp/.usrmnt
and a tab file). It should be noted that the mount right confirmation means 12 and the mount release right confirmation means 15 are usrrmntd (user m) on the client 10 side.
mount mount means 13 and mount release means 16 are mounted on the client 10 side by mountd (mount damon).
(meaning emon) is realized (usrmn
(td is a daemon specific to the present invention, mountd is an existing daemon in normal NFS).

The server 20 has a mount right confirmation means 21.
Share execution means 22 and password file 23
(/ Etc / passwd file) and share management file 24 ($ HOME / sharetab file)
It is configured to include and. The mount right confirmation means 21 and the share execution means 22 are usr on the server 20 side.
It is implemented by mntd (usrmntd is a daemon unique to the present invention).

FIG. 2 is a flow chart showing the processing when the mount is executed in the distributed file system of this embodiment. This process is performed by the server side mount request issuing step 201.
And a server side mount point inspection step 202,
Password file reading step 203, user name checking step 204, home directory recognition step 205, share management file reading step 20
6, share request acceptance / rejection checking step 207, share request issuing step 208, and share executing step 209
And client side mount request issuing step 210
And client side mount point inspection step 21
1, a mount execution request issuing step 212, a mount executing step 213, a mount success / failure checking step 214, a mount status description file writing step 215, a mount success notifying step 216, and an unshare request availability checking step 217, , Unshare request issue step 218 and unshare execution step 21
9, a mount end notification step 220, a mount execution processing end step 221, a server side failure notification step 222, and a client side failure notification step 223.
And a mount execution process end step 224.

FIG. 3 is a flow chart showing the processing at the time of unmounting in the distributed file system of this embodiment. This process is performed by issuing an unmounting request step 301, a mount status description file reading step 302, a corresponding entry presence / absence checking step 303, a corresponding entry absence notification step 304, and a user matching checking step 30.
5, a user mismatch notification step 306, a mount release execution request issuing step 307, a mount release step 308, and a mount release success / failure check step 30.
9, a mount status description file entry deletion step 310, and a mount release success / failure information holding step 3
11 and dismount success / failure information notification step 31
2, a dismounting process end step 313, and a dismounting process end step 314.

FIG. 4 is a diagram showing the format of the share management file 24. The share management file 24 has an entry for each directory (share target directory) for sharing. Each entry is a share target directory, a mount computer host name that indicates the host name of a computer that can be a mount source computer (client) when mounting based on the share, and (the host name of multiple computers in this item. Access right (information that matches the access right when mounting the directory, and "read only" is "r"
information indicated by "o" and "readable and writable" by "rw").

FIG. 5 is a diagram showing the format of the password file 23. Password file is UNI
It is a file that has existed conventionally in a distributed processing system that employs the X operating system, and includes a user name, password, and user id (identif
entry), group id, comment, home directory, and login shell (general user account corresponding to the entry)
have. In the present embodiment and the present invention, the user name, user id and group i in this entry are
d is used (password information can also be used to improve security retention).

FIG. 6 is a diagram showing the format of the mount status description file 17. The mount status description file 17 includes a “user name” for identifying a general user who has issued the usrmnt command (see below) and the u
It has an entry consisting of “mount point” indicating the client side mount point in the mount request based on the srmnt command.

Next, the operation of the distributed file system of this embodiment having the above configuration will be described. The basic protocol for mounting in the distributed file system according to this embodiment is based on the protocol in normal NFS.

First, the operation during the preparation process will be described.

First, the following environment settings are set.

“Command for general user to activate mount request issuing means 11 which is a non-resident process”
Usrmnt command (general user mount request command), and "a general user mounts the unusrmnt command (general user mount cancellation request command) for activating the mount cancellation request issuing means 14 which is a non-resident process. .

A resident process usrmntd is prepared for both the client 10 and the server 20.

Both the client 10 and the server 20 are set so as to be able to receive a normal NFS service.

Next, the privileged user activates usrmntd on the client 10 side and the server 20 side with his own authority.

Further, a general user who wants to use usrrmntd on the client 10 side and the server 20 side is a home directory ($) of the general user on the server 20 side.
The share management file 24 ($ HOME / sharetab) having a format as shown in FIG.
File). The share management file 24
Is created directly under the home directory of the general user in order to clarify the location of the share management file 24 of the general user. Therefore, if the location is clear, the share management file 24 can be created in a place other than directly under the home directory.

Secondly, the operation when the mount is executed will be described (see FIG. 2).

The general user on the client 10 side issues the usrmnt command when he wants to mount his or her own disk resource on the server 20 side.

The mount request issuing means 11 on the client 10 side is generated based on this usrmnt command, and issues a server side mount request to the server 20 side (step 201). The server-side mount request includes the service type (in this case, the server-side mount request), user name, user id, group id, client host name, server-side mount point, client-side mount point, and option ( The content of the option is arbitrary and may be omitted).

The mount right confirmation means 21 on the server 20 side that has received this server side mount request, based on the server side mount point in the server side mount request,
It is checked whether or not a directory corresponding to the server side mount point exists on the server 20 side (step 202).

The mount right confirming means 21 executes step 20.
When it is determined in the check of No. 2 that "the directory does not exist" (when the check result is "failure"), the fact is notified to the mount request issuing means 11 on the client 10 side (step 223), and the request is issued. Return to the waiting state.

On the other hand, when the mount right confirmation means 21 determines in the inspection of step 202 that "the directory exists" (when the inspection result is "success"), it has the format as shown in FIG. Password file 23
Is read (step 203), and it is checked whether or not there is an entry in the password file 23 that has information matching the user name, user id, and group id of the general user who issued the usrmnt command (step 2).
04).

The mount right confirming means 21 executes step 20.
When it is determined in the inspection of No. 4 that "there is no entry in the password file 23 having the information matching the user name, etc." (the inspection result is "failure"), the fact is mounted on the client 10 side. The request issuing means 11 is notified (step 223), and the process returns to the request waiting state.

On the other hand, when the mount right confirmation means 21 determines in the inspection of step 204 that "there is an entry having information matching the user name etc. in the password file 23" (the inspection result is "success"). In this case, from the entry, the home directory (the home directory of the general user on the server 20 ($ HOM
E)) is taken out and recognized (step 205).

The mount right confirming means 21 executes step 20.
The share management file 24 existing immediately below the home directory extracted in step 5 is read (step 206),
Based on the contents of the share management file 24 and the above-mentioned server side mount request, it is checked whether or not a share request should be issued to the share executing means 22 (step 207).
That is, whether or not there is an entry having the server-side mount point in the share-target directory in the server-side mount request in the share management file 24, and the host name of the client 10 is included in the mount computer host names in the entry. Check if

The mount right confirming means 21 executes step 20.
If it is determined in step 7 that "a share request should not be issued" (the inspection result is "failure"), the fact is notified to the mount request issuing means 11 on the client 10 side (step 223), and the request is awaited. Return to the state.

On the other hand, when the mount right confirming means 21 determines in the inspection of step 207 that "a share request should be issued" (when the inspection result is "success"), the mount executing means 22 instructs the share executing means 22. And issues a share request (step 208). Note that steps 202, 204 and 2
The case where all the inspection results of 07 are “success” corresponds to the case where there is a mount right (mount right on the server 20 side) related to the server side mount request.

The share executing means 22 shares the mount point (server side mount point in the server side mount request) based on the share request (step 209).

If the mount point has already been shared, the mount right confirmation means 21 retains information indicating that fact (for example, a flag indicating that). Set a bit on).

After confirming that the mount point has been shared, the mount right confirmation means 21 issues a client side mount request to the mount right confirmation means 12 on the client 10 side (step 21).
0). In this client-side mount request, the service type (in this case, client-side mount request), user name, user id, group id, server host name, server-side mount point, client-side mount point, and options are included. enter.

When the mount right confirmation means 12 on the client 10 side receives the client side mount request, the user name in the client side mount request,
Whether the directory corresponding to the client mount point is owned by the general user (general user identified by the user name, user id, and group id) based on the user id, group id, and client mount point. Is checked (step 211).

The mount right confirming means 12 executes step 21.
When it is determined in the inspection of 1 that "the directory (the mount point on the client side) is not owned by the general user" (when the inspection result is "failure"), that fact is confirmed by the mount right on the server 20 side. The means 21 is notified (step 222) to return to the request waiting state. Upon receiving this notification, the mount right confirmation means 21 notifies the mount request issuing means 11 on the client 10 side (step 223) and returns to the request waiting state.

On the other hand, the mount right confirming means 12 determines that "the directory is owned by the general user" in the inspection of step 211 (when the inspection result is "success"), the mount executing means 12 A mount execution request (a request for urging the mount of the mount point) to be issued to 13 (step 212). The case where the inspection result in step 211 is “success” corresponds to the case where there is a mount right (mount right on the client 10 side) related to the client side mount request.

The mount executing means 13 mounts the mount point based on the mount execution request (step 213).

The mount right confirmation means 12 executes step 21.
It is checked whether the execution of the mount 3 is successful or unsuccessful (step 214).

The mount right confirmation means 12 executes step 21.
If it is determined in the check of No. 4 that "execution of mount has failed", a notice indicating that (mount failure notification) is sent to the mount right confirmation means 21 on the server 20 side (step 222), and a request is awaited. Return to the state. The mount right confirmation means 21 which has received the mount failure notification notifies the mount request issuing means 11 on the client 10 side (step 223) and returns to the request waiting state.

On the other hand, when the mount right confirmation means 12 determines in the step 214 that "mounting has succeeded", the user name (in the mount status description file 17 of the format shown in FIG. usrmnt
Information indicating the user name of the general user who issued the command and the mount point (mount point on the client side) is written (step 215), and a notification (mount success notification) indicating that mounting is successful is sent to the server 20.
To the mount right confirmation means 21 on the side (step 2
16) Return to the request waiting state.

Mount right confirmation means 21 on the server 20 side
After receiving the mount success notification (the information indicating the server side mount point is included in this notification) from the mount right confirmation means 12 on the client 10 side, the server side mount related to the mount success notification is received. It is checked whether the points are actually shared in step 209 (step 217). This check is a check for determining whether or not an unshare request should be issued. For example, whether or not a bit is set in the "flag for indicating that the mount point is already shared" It is performed by determining.

The mount right confirmation means 21 executes step 21.
When it is determined in the inspection of 7 that "the mount point on the server side is actually shared in step 209 (should issue an unshare request)", an unshare request for that location (mount point on the server side) Is issued to the share executing means 22 (step 218).

The share executing means 22 executes the unshare (release of the mount permission) of the location based on the unshare request (step 219). Even if the execution of this unshare fails, no special measures are taken and it is ignored.

The mount right confirming means 21 executes step 21.
If it is determined in the inspection of 7 that “the mount point on the server side is not actually shared in step 209 (the unshare request should not be issued)” or if the execution of unshare in step 219 is completed, the client 10 The mount request issuing means 11 on the side is notified (mount end notification) indicating that the above-described series of processing has been normally completed (step 220), and returns to the request waiting state.

Upon receiving the mount end notification, the mount request issuing means 11 on the client 10 side ends the mount execution processing in this embodiment (step 22).
1). That is, the fact that the mount execution processing has been normally completed is displayed on the screen and the processing is ended.

When the mount request issuing means 11 receives a notification of failure from the mount right confirming means 21 on the server 20 side (see step 223), it displays that fact on the screen and terminates the mount execution processing ( Step 22
4).

The display on the screen in step 221 and step 224 allows the general user to recognize the success / failure of mount.

Third, the operation at the time of releasing the mount will be described (see FIG. 3).

The general user on the client 10 side issues the unusrmnt command when he wants to release the mount.

The mount release request issuing means 14 on the client 10 side is generated based on this unusrmnt command and issues a mount release request to the mount release right confirming means 15 (step 301). The type of service (in this case, the unmount request), the user name, and the unmount point are included in this unmount request.

When the mount release right confirmation means 15 receives the mount release request, the mount status description file 1
7 is read (step 302), and the entry having the mount point corresponding to the mount point in the mount request is the mount status description file 17
(See FIG. 6).
03).

When the mount release right confirmation means 15 determines in the inspection of step 303 that "the corresponding entry does not exist in the mount status description file 17" (when the inspection result is "failure"), it indicates that fact. Is notified to the mount release request issuing means 14 (step 304), and the process returns to the request waiting state.

On the other hand, when the mount release right confirmation means 15 determines in the inspection of step 303 that "the relevant entry exists in the mount status description file 17" (when the inspection result is "success"), The user corresponding to the entry (general user identified by the "user name" in the entry) is the unus related to the mount release request.
It is checked whether or not the user is an ordinary user who has issued the rmnt command (whether the users match) (step 30).
5).

When the dismounting right confirming means 15 determines in the inspection of step 305 that "the users do not match" (when the inspection result is "failure"), the dismounting request issuing means 14 is notified to that effect. Notify (Step 30)
6) Return to the request waiting state.

On the other hand, when the dismounting right confirming means 15 determines in the inspection of step 305 that "the users match" (when the inspection result is "success"), the dismounting right confirming means 15 mounts the dismounting means 16. A cancellation execution request (a request for urging the cancellation of the mount of the mount point) is issued (step 307). It should be noted that the case where all the inspection results in steps 303 and 305 are “success” corresponds to the case where there is the unmount right regarding the unmount request.

In response to the mount release execution request, the mount release means 16 releases the mount at the mount point (mount point in the entry detected by the inspection in step 303) (step 30).
8).

The mount release right confirmation means 15 checks whether the mount release in step 308 has succeeded or failed (step 309).

When the mount release right confirmation means 15 determines in the step 309 that the mount has been released successfully, it deletes the entry having the mount point from the mount status description file 17 (step 310). .

On the other hand, if the mount release right confirmation means 15 determines in step 309 that the mount release has failed (for example, if the directory corresponding to the mount point is in use), a special Ignore without taking action (control is transferred to the process of step 311).

Further, the mount release right confirming means 15 holds therein information indicating whether the mount release is successful or unsuccessful and information indicating the cause in the case of failure (step 311).

Further, the mount right release confirmation means 15 is
The information held in step 311 is notified to the mount release request issuing means 14 (step 312), and after notification, the process returns to the request waiting state.

The mount release request issuing means 14 displays the mount release success / failure result or the like on the screen based on the notification of step 312, and ends the mount release processing in this embodiment (step 313).

The mount release request issuing means 14
When the notification from the mount right release confirmation means 15 in step 304 or 306 is received, a message to that effect is displayed on the screen and the mount release process is terminated (step 3).
14).

The display on the screen in step 313 or step 314 allows the general user to recognize the success / failure of the mount release.

With the above-described processing, it is possible to execute the mount and release of the mount from the client 10 to the server 20 according to the general user's request. here,
As described above, the presence of the mount right is recognized only when the general user who requests the mount (mount request issuer) satisfies the following conditions (1) to (3), so that security is maintained in the distributed processing system. Is protected.

The server 20 has an account of the mount request issuer (the password file 23 contains the user name, user id, and group id of the mount request issuer).

The owner of the directory corresponding to the mount point on the server side matches the mount request issuer

The directory corresponding to the mount point on the server side is under the home directory of the mount request issuer.

The directory corresponding to the mount point on the client side is owned by the mount request issuer.

[0086]

As described above, the present invention provides usrm
nt command (general user mount request command) and unusrmnt command (general user mount release request command) are provided, and usrmntd (mount right confirmation means, mount release right confirmation means and share execution means) are provided on the client side and the server side, By providing the mount status description file and the share management file, etc., it becomes possible for general users to freely mount their own private disk resources on other computers while maintaining security. Have (easy access to the file on the disk resource). That is, in normal NFS, it is possible to give the authority of the mount request, which was given only to the privileged user for security reasons to the general user other than the privileged user, and the general user freely mounts his or her own disk resource ( There is an effect that a method capable of (NFS mount) can be established.

As a result of such an effect, a general user who has an account on a plurality of computers can access the disk resources owned by himself or herself from any computer without being aware of the network. The following effects are produced.

It facilitates the transfer of personal disk resources between networks.

Once mounted, the disk resources of the other computer on the network can be used without logging in to the other computer on the network.

Since personal disk resources can be distributed and held, it is not necessary for each general user to have the same file in each computer, and it is possible to save disk resources in the entire distributed processing system.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of an embodiment according to a distributed file system of the present invention.

FIG. 2 is a flowchart showing mount execution processing in the distributed file system shown in FIG.

FIG. 3 is a flowchart showing a mount release process in the distributed file system shown in FIG.

FIG. 4 is a diagram showing a format of a share management file in FIG.

5 is a diagram showing a format of a password file in FIG.

FIG. 6 is a diagram showing a format of a mount status description file in FIG.

[Explanation of symbols]

 10 client 11 mount request issuing means 12 mount right confirming means 13 mount executing means 14 mount release request issuing means 15 mount release right confirming means 16 mount releasing means 17 mount status description file 20 server 21 mount right confirming means 22 share executing means 23 password File 24 Share management file

Claims (4)

[Claims] 1. In a distributed processing system in an environment in which NFS can be used, a password file on the server side that manages the account of a general user who owns disk resources on the server side, and a password file provided for each general user are provided. A share management file on the server side that manages information about shares about users, a mount status description file on the client side that holds information indicating the mount status for each general user, and a server-side mount request based on the general user mount request command. Confirms the presence or absence of the mount right on the server side regarding the server side mount request issued by the mount request issuing means by referring to the mount request issuing means on the client side and the password file and the share management file, Mount right A server-side mount right confirmation means that issues a share request when it is determined, and a server-side share execution means that executes share based on the share request issued by this server-side mount right confirmation means, and this share After the share is successfully executed by the executing means, the client side mount request issued from the mount right confirming means on the server side is received, and the presence or absence of the mount right on the client side regarding the client side mount request is confirmed. If it is determined that there is a mount execution request, if the mount execution based on the mount execution request is successful, the mount right confirmation means on the client side that writes information indicating that to the mount status description file, The mount issued by the mount right confirmation means on the client side Refer to the mount execution means on the client side that executes the mount based on the execution request, the mount side dismount request issuing means that issues the dismount request based on the general user dismount request command, and the mount status description file Then, the client side unmount right confirmation means for checking the presence or absence of the unmount right regarding the unmount request issued by the unmount request issuing means, and issuing the unmount execution request when it is determined that the unmount right is present. And a client-side unmounting unit for unmounting based on an unmounting execution request issued by the unmounting right confirmation unit. 2. The distributed file system according to claim 1, wherein the entry in the share management file comprises a share target directory, a mount computer host name, and an access right. 3. The distributed file system according to claim 1, wherein the entry in the mount status description file comprises a user name and a mount point. 4. The distributed file system according to claim 1, wherein a share management file of a general user is directly under the home directory of the general user.