It's kind of a fuzzy distinction, since you are trying to satisfy a diverse set of applications, but in general, EPERM ("Operation not permitted") is used to bounce attempts to do things that don't work because you're not the right UID/GID, whereas EACCESS ("Permission denied") is used when the object in question does not grant you access.

In the case of NTFS qtrees, I think you could argue it either way, but to me it feels more like you're the "wrong user" than "this object denies access". We have plans to allow users from UNIX clients to manage NT ACLs on the filer, which would allow you to see what is going on in cases like this. In the meantime, now that the Samba team has published the necessary DCE/RPC info to do this*, there's nothing stopping some enterprising third party from providing such a command. Any takers? :-)

Mark Muhlestein -- mmm@netapp.com

*See Luke Leighton's book _DCE/RPC over SMB: Samba and Windows NT Domain Internals_ from Macmillan Technical Publishing. The Samba "rpcclient" utility gets you 95% of the way there. If anyone seriously wants to try this, let me know.

-----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Wednesday, March 08, 2000 4:11 AM To: Bond, Andrew; bhaskar.g@philips.com; toasters@mathworks.com Subject: Re: Problem in ownerships

----- Original Message ----- From: Bond, Andrew abond@netapp.com To: bhaskar.g@philips.com; toasters@mathworks.com Sent: Wednesday, March 08, 2000 3:42 AM Subject: RE: Problem in ownerships

I'd take a quess that the file is on a qtree (or volume) with NTFS

security.

This is expected behaviour in that situation.

Good point. I would have expected a different error message (EACCES rather than EPERM), but it appears that chown(2) and utimes(2) may interpret those very strictly, and assume that EPERM must mean that you are not the owner if you're not root, rather than simply being denied write access. They don't seem to consider the possibility of being denied write access even when the times argument is non-NULL.

Still, wouldn't it be more appropriate for the filer to return NFS[3]ERR_ACCES instead of NFS[3]ERR_PERM in those situations?

Bruce