Q re POSIX->NT->POSIX error mapping

Green, Paul Paul.Green at stratus.com
Fri Jan 22 15:21:16 MST 2010

Volker Lendecke wrote:

> On Tue, Jan 19, 2010 at 04:28:10PM -0500, Green, Paul wrote:
> > O6. As of 2009-07-14, Samba maps ENOSYS to 
> > NT_STATUS_NOT_SUPPORTED. ...[snip]...
> >
> > As far as I can tell, this NT error
> > won't produce the EOPNOTSUPP error on the POSIX end of 
> > things, and so this case will still fail.
> in unix_dos_nt_errmap seems the right thing to do, as it is
> done right now in master and earlier versions. What do you
> mean by "won't produce the EOPNOTSUPP error on the POSIX end
> of things"?

I should have said "on the client end;" i.e., on the Linux system where
the sftp command is running. I apologize for the poor choice of words.

> Does cifsfs not map this back to ENOSYS or
> NOTSUPP (whatever link(2) is allowed to return)?

No, and just to be certain, we took sftp out of the picture. We wrote a
short test case that just called the link function on Linux, which was
then processed via the CIFS software over to Samba on VOS. (Recall that
the VOS version of the POSIX link function always returns ENOSYS).

With the standard Samba 3.2.4 code, we get back "Permission Denied."

If we change Samba to use either of these two mappings:



we get "Bad Message" as the error displayed by sftp.

With our patch:

	{ ENOSYS, ERRDOS, ERReasnotsupported,

we get ENOTSUPP sent to sftp, which is what we want and need.

Until someone else bumps into a similar issue, this may just not be
worth the time and effort to understand & resolve. I have a local fix to
our port of Samba that will work for us.  I just wanted the team to be
aware that some of the error numbers generated by Samba don't seem to be
surviving their trip thru CIFS. Or to put it another way, SMBFS and CIFS
appear to behave differently with respect to mapping errors between the
Windows and POSIX worlds. That's not all that surprising.


More information about the samba-technical mailing list