Drive Mounted with Foreign Qualifier

[fastfreddy]

A drive was mounted using the following command
MOUNT/FOR $1$DUA32 HIST

This caused the following result.

Device Device Error Volume
Name Status Count Label
$1$DUA32:(HSC003) Mounted alloc 0 HIST
foreign wrtlck

How do I dismount the drive such that it can be mounted properly?

Thanx Fred

[Jan van den Ende]

Fred,

$ HELP is your friend! Try it.

And, this being VMS, you might try to guess the commands.

The command to dismount a drive is...
$ DISMOUNT
so, to dismount $1$DUA32 :
$ DISMOUNT $1$DUA32

The same principle holds for all commands (but sometimes you WILL have to search dor the correct synonym)

Proost.

Have one on me.

jpe

[Aaron Sakovich]

So you're saying that when you mounted it foreign, it mounted it foreign AND write-locked it? Curious...

$ Dismount Disk$Hist
or
$ Dismount $1$DUA32:

by itself should work. Of course, if you logged out, it should dismount automatically since the device is allocated to your process and you didn't do a /Group or /System mount (which you can't with a /Foreign device anyways, so I don't know why I brought that up!)

[fastfreddy]

That was the first command that I tried.

$dismount/override=checks $1$dua32:
%DISM-W-CANNOTDMT, $1$DUA32: cannot be dismounted
%SYSTEM-F-DEVNOTMOUNT, device is not mounted

[labadie_1]

Are you in a Cluster ?

Maybe you mounted it on a node, and try the dismount on another Cluster node ?

[fastfreddy]

Just to clarify the issue the command was not issued by me rather by someone with limited OpenVMS knowledge.

The device was formerly a member of a shadow set that became dis-functional due to controller problems which since have been resolved.

The drive came back online and was then incorrectly mounted as foreign and cannot be dismounted because of a mounted allocate foreign writelock condition.

$ dismount/override=checks $1$dua32:
%DISM-W-CANNOTDMT, $1$DUA32: cannot be dismounted
%SYSTEM-F-DEVNOTMOUNT, device is not mounted

The process that mounted it has logged off.

How do I clear this condition such that the device can be dismounted and re-mounted as part of its shadow set.

Thanx Fred

[Jim_McKinney]

This volume was mounted privately and must be dismounted by the same process that performed the mount (an implicit dismount would occur if that process was to log out). You can determine the owner process using

$ show device/full $1$DUA32:

[fastfreddy]

This is a clustered environment but no attempt was made to mount it on the other node. It shows the same condition on the other node but as a remote mount.

Thanx Fred

[Jess Goodman]

If we could see the output from a SHOW DEVICE/FULL command, that would be a big help.

Did you try DISMOUNT/ABORT (I'm guessing that the volume is in mount verification).

[Hoff]

The volume appears mounted privately, given the allocation and given the command shown. Issue the DISMOUNT in the same process that issued the MOUNT, or issue a LOGOUT and cause that whole session to log out and which will then allow the automatic DISMOUNT(s) to run.

This case is sometimes called "operator error", and it's among the most common ways to trash production data and/or the system uptime stats.

The following is not intended as personal nor as rude, and I do not care who issued the errant commands. Mistakes happen. What follows is what I've learned from similar mistakes and errors I've encountered over the years.

Access to and the errant use of core OpenVMS system management commands such as MOUNT -- combined with inexperience or incautiousness -- is a very bad combination for continued data integrity and for continued operations in production configurations.

Here, I'd remove any and all non-default privileges from the user involved; from whomever issued the MOUNT command.

This for the continued integrity of the production data and the production environment. Not as punishment. "Privileges" are better thought of as "Responsibilities", and are the central mechanisms used by OpenVMS to protect against "operator error".

Next up would be creating or working with automated or local or tailored DCL procedures to perform whatever the target task might be. This to remove the need for privileges.

How good are the local disk backups, and how current are they? Given what I'm reading and what I'm inferring here, I could easily see an errant DCL command leading to data loss or downtime.

Mistakes can and do happen, and learning from and particularly working toward reducing exposure to future and similar mistakes is how better uptime is achieved. This can be through canned procedures, site policies, OpenVMS training, use of least privileges, or other approaches.

Stephen Hoffman
HoffmanLabs LLC

[Jan van den Ende · Accepted solution]

Fred,

>>>
$1$DUA32:(HSC003) Mounted alloc 0 HIST
foreign wrtlck
=== and ===
$ dismount/override=checks $1$dua32:
<<<

Foreign mount can only be process-private.
So, that process DOES still exist!

As already said, SHOW DEV $1$DUA32 /full DOES show the owner PID.

If you can not locate who that is, do a STOP/ID for that PID.
That SHOULD release the drive, unless for some reason the process CANNOT be deleted.

In that case, THAT is your real problem, but let us not look too far ahead.

Proost.

Have one on me.

jpe

[Jan van den Ende]

Oops.

Hit Submit a little bit too quick.

>>>
$ dismount/override=checks $1$dua32:
<<<

I was going to add:

/override=checks does not apply for foreign mounted devices.

Proost.

Have one on me.

jpe

[fastfreddy]

Problem solved.

I was told that the process that had performed the incorrect MOUNT had logged off but it hadn't so the device was still allocated to the process.
When I killed the process the device was deallocated and dismounted.

It is now properly mounted and in the process of doing a shadow copy.

My BAD I should always verify what I have been told.

I agree with the comment the least amount of priviledges in case of lack of knowledge but it is not practical in this case because this person is a senior member of the support team and requires this level of priviledge to perform their duties.

I am only a "contractor" brought in to assist the team need I say more.

[fastfreddy]

I was told that the process that had performed the incorrect MOUNT had logged off but it hadn't so the device was still allocated to the process.
When I killed the process the device was deallocated and dismounted.

It is now properly mounted and in the process of doing a shadow copy.