It's a real pain not having a spare filer to test things on ...
I was hoping that all the quota-related nasties (153377, 154530) were well and truely fixed now and that I wouild be able to upgrade from 6.5.4 to 7.0.1R1(maybe P<something>) later this month. But then this appears on NOW:
Bug ID 155441 Title: cp -p, chown, chgrp may erroneously fail due to "Disk quota exceeded" Description: If the default user or group quota for a volume or qtree is set lower than the size of the file whose permissions are being set, the command will fail due to an incorrect assertion that it would put the user over quota. This problem does not manifest when the command is executed by root.
I am assuming that this is Yet Another Bug new in ONTAP 7.x, as AFAIK we have never seen the effect, and it seems to me we would surely be liable to.
Specifically, we have a zero default quota in our /home qtree:
* user@/home 0 0 101 user@/home 80M 8000 102 user@/home 210M 8000 ...
specifically intended to lock out unallocated uids, special uids that aren't meant to be using /home, cancelled accounts, and so on. It works very well.
Has anytoaster suffered the effect described in the bug report?
It's a real pain not having a spare filer to test things on ...
I was hoping that all the quota-related nasties (153377, 154530) were well and truely fixed now and that I wouild be able to upgrade from 6.5.4 to 7.0.1R1(maybe P<something>) later this month. But then this appears on NOW:
Bug ID 155441 Title: cp -p, chown, chgrp may erroneously fail due to "Disk quota exceeded" Description: If the default user or group quota for a volume or qtree is set lower than the size of the file whose permissions are being set, the command will fail due to an incorrect assertion that it would put the user over quota. This problem does not manifest when the command is executed by root.
I am assuming that this is Yet Another Bug new in ONTAP 7.x, as AFAIK we have never seen the effect, and it seems to me we would surely be liable to.
Specifically, we have a zero default quota in our /home qtree:
user@/home 0 0101 user@/home 80M 8000 102 user@/home 210M 8000 ...
specifically intended to lock out unallocated uids, special uids that aren't meant to be using /home, cancelled accounts, and so on. It works very well.
Has anytoaster suffered the effect described in the bug report?
I just tried it on a R200 running 7.0.1R1 and I didn't see a problem. I had this quota file:
* user@/vol/vol0 0 0 503 user@/vol/vol0 500M 500K
I turned on quotas
quota on vol0
I created a file as root and chowned it to user 503 and it worked fine. I ran quota report and it was correct.
Notice that the bug report says this:
This problem does not manifest when the command is executed by root.
Are your Unix systems and filer configured to allow non-root users to chown files? It is possible but very unusual, especially if you are using quotas, since than a user could get around a quota by giving his files away. See options wafl.root_only_chown
Usually non-root users can only chgrp files and only to a group where the user is a member. If only root can chown and you aren't using group quotas, then I think you should be OK.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
Steve,
Many thanks for taking the time to set up the experiment:
I just tried it on a R200 running 7.0.1R1 and I didn't see a problem. I had this quota file:
- user@/vol/vol0 0 0
503 user@/vol/vol0 500M 500K
I turned on quotas
quota on vol0
I created a file as root and chowned it to user 503 and it worked fine. I ran quota report and it was correct.
Notice that the bug report says this:
This problem does not manifest when the command is executed by root.
Indeed...
Are your Unix systems and filer configured to allow non-root users to chown files? It is possible but very unusual, especially if you are using quotas, since than a user could get around a quota by giving his files away. See options wafl.root_only_chown
No, we don't allow non-root chown's, and have no desire to. It was the reference to chgrp and "cp -p" that worried me.
Usually non-root users can only chgrp files and only to a group where the user is a member. If only root can chown and you aren't using group quotas, then I think you should be OK.
Ah! It hadn't occurred to me that the problem with chgrp might only occur if one had per-gid quotas (or even more, a _default_ per-gid quota), rather than per-uid ones. The problem description doesn't actually say that, but it would certainly make sense. We don't use per-gid quotas, so maybe we are OK after all. [*]
What do you make of the reference to "cp -p"? Just that the setting of the owner and/or group might wrongly fail, not the rest of the copying?
[*] And as an afterthought, maybe it's not a new-in-7.x bug after all. My recollection is that the bug descriptions on NOW used to have "reported-in-version" and "probably-in-versions" fields in them, but they don't seem to any longer: just a "fixed-in-version" one :-(
-
Chris Thompson -
Steve Losen