Write failures and proper error code return to clients

Shlomi Yaakobovich Shlomi at exanet.com
Tue Jul 25 06:06:57 GMT 2006


> Ok, I've now had time to look at this.
> You missed this code in reply_write_and_X() :
>         if(((nwritten == 0) && (numtowrite != 0))||(nwritten < 0)) {
>                 END_PROFILE(SMBwriteX);
>                 return(UNIXERROR(ERRHRD,ERRdiskfull));
>         }

This actually should be:

        if(((nwritten == 0) && (numtowrite != 0))||(nwritten < 0)) {
                if (errno == EDQUOT) {
                    return ERROR_NT(NT_STATUS_QUOTA_EXCEEDED);

The reason is that a windows client 2003 and down, for both errors (disk full and quota exceeded) the error message will be "There is not enough space on the disk". Only for XP client a user will get different error message: "Not enough quota is available to process this command", which is the right one in case of a quota error. Dina Fine found this out and added the above fix. BTW, I think this is relevant to all types of writes, not just the specific case we've mentioned here. E.g I saw your latest checkin (17220) in reply.c, I believe this is the same there as well.

Regarding the quota change, perhaps it will be better to change it in error.c, e.g. like this (in errormap.c):

#ifdef EDQUOT

> UNIXERROR looks at errno. What is errno set to in your
> particular case ? The default of ERRdiskfull is only
> returned if errno == 0.

It also returns ERRdiskfull  if it does not find the exact errno in the unix_dos_nt_errmap array. This was the case here, the errno was 105 (ENOBUFS - No buffer space available). This might be related to the kernel/NFS client, but samba currently is unaware of this error code. I'm not sure it should be though, it clearly indicates a problem. In our case the problem was transient, a second retry (when encountering this error) was successful.

Anyways, I'm still not sure what caused the ENOBUFS error, maybe it is indeed only when writing to NFS mounts. In the meantime, since we needed to apply a quick fix, we just added 2 more retries, which apparently made our problem disappear (not get solved...).


More information about the samba-technical mailing list