diskqota exceeded message although it is not

[mustafa_12]

hi all,

when I say, "show quota" it gives

$show quota
User [xg,xu] has 256346 blocks used, 39743654 available,
of 40000000 authorized and permitted overdraft of 20000000 blocks on $DISK34



but when I try to copy a file

$copy a.log b.log
%COPY-E-OPENOUT, error opening $DISK34:[LOGS.COMM_SERVER.OUT_DATA]B.LOG; as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded
%COPY-W-NOTCOPIED, $DISK34:[LOGS.COMM_SERVER.OUT_DATA]a.log;2 not copied


How can this be possible, although there is enough disk quota for the user?

[Duncan Morris]

Hi Mustafa,

check the ownership of the newly copied file. You may find that it inheriting ownership from the directory or a previous version of that file.

Once you know the new owner, then check the disk quota for _that_ owner, and not just for yourself.

[Arch_Muthiah]

Mustafa,

Before knowing whether your username have quota entry in the specific disk volume, would you give the file size (a.log), because overdraft blocks can not used by normal user files unless system a/c give permission.



Archunan

[Arch_Muthiah]

Miles,

I have two doubts one is your username may not have entry in the quota file for that volume. But if that is tha case, if you have executed the command $show quot from that user account, it should show "%SYSTEM-F-NODISKQUOTA, no disk quota entry for this UIC". As you did not get this error, looks like that the username has quota entry, but
he may not have write access privilege to $DISK34:[LOGS.COMM_SERVER.OUT_DATA] dire.

Make sure you have write acccess priv on that dire.

also go thru this similar issue
http://groups.google.com/group/comp.os.vms/browse_thread/thread/7b60f11d5b4cb07d/ea76456f09feab97?lnk=st&q=VMS+RMS-E-CRE+SYSTEM-F-EXDISKQUOTA%2C+disk+quota+exceeded&rnum=7&hl=en#ea76456f09feab97


Archunan

[Robert Gezelter]

mustafa,

Please do a DIRECTORY/FULL on $DISKS34:[LOGS.COMM_SERVER]OUT_DATA.DIR and a
DIRECTORY/FULL on $DISK34:[LOGS.COMM_SERVER.OUT_DATA]B.LOG.

Then post the output to this forum.

- Bob Gezelter, http://www.rlgsc.com

[Uwe Zessin]

> there is enough disk quota for the user?

mustafa,

disk quota works with UICs (e.g. [36,47]), not usernames.

[Ian Miller.]

It may also be worth doing a
MCR DISKQUOTA REBUILD

[Steven Schweda]

> disk quota works with UICs (e.g. [36,47]), not usernames.

So, this really didn't work?

ALP $ sysman diskquota show sms /device = home_sms
%SYSMAN-I-QUOTA, disk quota statistics on device ALP$DKA0: --
Node ALP
UIC Usage Permanent Quota Overdraft Limit
[SMS] 5395654 20000000 1024000

ALP $ version
V7.3-2

Or what did you mean?

[Volker Halle]

Steven,

your 'user name' SMS used in the context of DISKQUOTA is nothing else than an IDENTIFIER name for your UIC

UAF> SHOW/ID SMS
Name Value Attributes
SMS [000grp,000mem]

A SYSMAN diskquota show [grp,mem] /device = home_sms would have reported the same results.

Volker.

[Uwe Zessin]

Right, try this if you want to dive a bit deeper:

UAF> rename /identifier SMS SMS2
UAF> show SMS

$ mcr sysman diskquota show sms2 /device = home_sms
$ mcr sysman diskquota show sms /device = home_sms

[Jan van den Ende]

Mustafa,

as far as I can see from your info, the first answer (by Duncan) looks to be correct.
But why did it happen?

First, DISKQUOTA is per device, per UIC.

SHOW QUOTA gives the quota for 'your' (the asking process) UIC, for the current default device,

MCR DISKQOTA does the same, but it also takes params.

MCR DISKQUOTA or specifies a particular user

MCR DISKQUOTA/DEVICE=$DISK34 shows quota for THAT device.

Of course those can be combined.

The other complication stems from the file OWNERSHIP.
Especially with SYSPRV (for some ownerships, also GRPPRV) COPY does some complex ownership manipulation, optimised to do it "right" most of the time for System Managers that have to transfer files across ownerships.
If you do not explicitly specify, then file ownership will be: (first one takes precedence)
- any explicitly specified on the command
- any existing file with same target name
- the ownership of the directory the file is created in.

Special considerations: if the existing file (or parent directory) is owned by an identifier that has the /RESOURCE attribute, than the created fil will also have that ownership, IF THE PROCESS THAT DOES the file ceation also has that identifier (regardless of privileges).

Now quota comes into play again: IF quota are enabled on the target volume, THEN the so decided file owner must have enough quota to accomodate the new file. If not, the error you get is issued.

So, check intended ownership, and check quota for that owner on that device.

hth

Proost.

Have one on me (maybe at the Bootcamp in Nashua?)

jpe