Strange RMS CONVERT error

[Rob Crooks]

I am frustrated with a new error i am getting when trying to do a convert on a file. Been using convert for years, but last week it suddenly started generating CONV-F-OPENOUT error.

I have a userid (ftpuser) that creates text files in a directory called [ftpuser]. They have a UIC of [240,0]. The directory [ftpuser] and all the files therein have s:wred,o:wred,g;wred,w:re permissions.
When they try to run a convert on a text file
"convert /fdl=ftptype.fdl chem1.txt chem1.ok"
I get CONV-T-OPENOUT (error opening chem1.ok as output) and RMS-E-PRV (insufficient priv or file protection violation) errors.

Logged in as ftpuser, I can create files in the directory fine, but the only way i can get the convert to work is to use another account that has BYPASS privs.

I cannot think of anything that has changed that would have caused this, and it makes no sense. The user has rights to open/read/write all files in his directory, but convert can't seem to do it.

I'm at a loss as to where to start troubleshooting.

Can anyone shed some light on this?

Thank you

[Bill Hall]

Check the security on the parent directory and verify the process account has write access to that directory. Check the fdl for either an OWNER entry or a PROTECTION entry that the process doesn't have privilege to do.

The correct fix for the problem will be specific to your site and security environment.

Bill

[Hoff]

To identify the directory or the file and the access request that is involved, enable file access failure audits (or alarms) and trace the failure through the security subsystem of OpenVMS. See SET AUDIT and ANALYZE /AUDIT for the commands used here.

Once enabled, try the (failing) operation, then check the audits.

If the system is busy, you might have to be quick about the enable-test-disable sequence.

And do see if there are any surprising logical names around, such as CHEM1, that might point the reference somewhere unexpected.

And FWIW, [*,0] is somewhat of a weird UIC value. Most UIC values are typically chosen as non-zero. (Probably not related here, though.)

[John Gillings]

Robert,

Curiously enough this may be the result of running CONVERT with too much privilege!

I'm not sure if I remember the exact details, but it's something like this...

When SORT (and therefore CONVERT) create work files, it hardcodes the protection mask to (S,O:RWD,G,W). When files are created in a shared directory, and the new sortwork file is the same name as an old one, a NONPRIVILEGED user will create a file owned by themselves, and can therefore delete it. However, a SYSPRV user will create a file owned by the previous owner and therefore CANNOT delete it (without BYPASS).

If that's not the problem, some things to try:

Check for old SORTWORK files. Make sure they're not in active use and delete them.

Define logical names for SORTWORK and CONVWORK to be unique filenames (see lexical function F$UNIQUE())

Also check the ownerships and protections of any files for which you're trying to create new versions.

Use SET WATCH/CLASS=MAJ to see what file operations are being performed

Enable auditing for file access failures

[Jon Pinkley]

RE:"I have a userid (ftpuser) that creates text files in a directory called [ftpuser]. They have a UIC of [240,0]. The directory [ftpuser] and all the files therein have s:wred,o:wred,g;wred,w:re permissions.
When they try to run a convert on a text file
"convert /fdl=ftptype.fdl chem1.txt chem1.ok"
I get CONV-T-OPENOUT (error opening chem1.ok as output) and RMS-E-PRV (insufficient priv or file protection violation) errors."
----------------------------

Is it only the specific file chem1.ok that can't be created?

Please do this:

$ directory/security chem1.ok

My guess is that the previous version of this file either has an ACL that is preventing the user running the convert from creating a new version (they need write access to the previous version of the file to be able to create a new version of it, since it effect, for many operations creating a new version is nearly the same as modifying the previous "highest version".

Perhaps the owner of the highest version of the file isnâ t [240,0] any more.

This is one reason I prefer to use directory/security instead of directory/protection, it shows all security related info (protection mask, ACL and owner), not just the protection mask.

Jon

[Hein van den Heuvel]

John G probably nailed it.
What does the FDL do?
Going to indexed?
Share it as a .TXT attachement?

Reduce the FDL file to just a FILE section with just OWNER and PROTECTION and the RECORD section. Now does the convert work?

As always, when in doubt on file access stuff check AUDTING, or...
grab CMKRL
and SET WATCH FILE/CLA=ALL

Cheerio,
Hein.