[lug] Sun Client Redhat AS3 NFS Probs

[D. Stimits]

Jeffrey A. St. Pierre wrote:
> On Sun, 16 May 2004, Hugh Brown wrote:
> 
> 
>>>>Have you tried to rebuild the quota files?
>>>>
>>>>
>>>
>>>There are no quotas setup, why should I have to rebuild the quota
>>>files?  Of course, Ie only used quotas on Sun systems in the
>>>past, is there a big difference moving to Linux?
>>>
>>>-Jeff
>>
>>chances are the sun and the linux clients are trying to follow quota
>>restrictions, talk to rquotad on the server, rquotad can't reply with
>>the quota info and outputs an error to syslog.
>>
>>so, you can probably take care of your errors by either turning off
>>rquotad or by setting up the quota files.
>>
>>Hugh
>>
> 
> OK, so you are telling me that every exported filesystem requires
> a quota file?  So I have three choices 1. to turn rquotad off 2.
> put every single exported filesystem under quota control, or 3.  
> deal with errors
> 

At least for testing. Until you know for sure what is happening, it's 
one way to figure it out.

> To me that would seem like a massive oversight in whoever wrote
> 'quota'.  I mean, what if I only want quotas on my home
> directories but not my project directories?  Anyway... let's give
> it a try.  Odds are you guys know more than I do about this
> stuff.
> 

Quota is a facet of security. Denial of service through remote 
filesystem exploit to fill up the drive with nonsense is one example. 
The whole point of quota is that you can't find a way around it if it is 
active. If either you have the feature added in, or if the filesystem 
type requires the feature, then a logged warning is pretty mild.

> Edit /etc/fstab on the server and remount the exported
> filesystems... just out of curiosity we'll run 'quota -v' on the
> client before we actually setup the quota file...  Oooo.  We have
> a new error message:
> 
> May 17 09:32:03 <server> rpc.rquotad: Quota file not found or
> has wrong format.  That's interesting.
> 
> Now let's setup the quota files: 
> 
> -bash <server:~> sudo quotacheck -acug
> 
> and now run 'quota -v' on the client again and... bingo! no
> errors.  Boy, y'all do know what you are talking about (wink). 
> 

Actually, you might say it was the logging system that knew what it was 
talking about :P But hey, credit to all who responded.

> Thanks much to everyone who gave me input on this.  However, I
> still feel this is a bit of a bug.  If there are no quotas setup
> for a particular filesystem, doesn't it make more sense for the
> daemon to just ignore the request for that filesystem, rather
> than filling the messeges file with ambiguous errors? I mean
> 'rpc.rquotad: Can't find filesystem mountpoint for directory
> /export/rd02/diag' seems unrelated to the actual problem.  If
> it insists on giving an error, don't you think 'No quota files
> for filesystem /mnt/filesystem' would be a better error
> message? Do you think I should report this to the developers?

Error messages being either misleading or lacking detail has been a 
problem since the beginning of computers. A better error message might 
be something worth mentioning to the developers. If this were something 
you'd seen before, you could go right to the fix, so to the developers 
the message probably isn't misleading until they hear from someone that 
had the problem while also unfamiliar with the setup.

D. Stimits, stimits AT comcast DOT net