I have used DOS FILEMODE = YES successfully and have verified correct operation by manually performing file operations using Windows explorer. I have system, hidden, archive and read-only bits all mapped My Linux platform is Ubuntu Server Edition 6.06 LTS. I do *not* use extended attributes *nor* do I have ACLs enabled. On closer inspection, I noticed that certain file operations produce ACCESS DENIED messages if the target files/directories are *not* owned by the logged on user. The bug is most likely to happen with XCOPY or when logging off with a non-mandatory roaming profile. I am unable to update to latest Samba release but have not found a bug fix since 3.0.22 so I assume it is still there. This is a serious bug as the whole point of DOS FILEMODE is to avoid the necessity for ownership.
This has nothing to do with ntlm_auth.
I have just isolated the *definite* cause of this bug. On further investigation, I noticed that the problem related to the archive bit which is of course mapped to the owner execute bit. I do understand that DOS attribute mappings will not work for directories. But then why does the problem only happen when the logged on user is *not* the owner? It seems that in DOS FILEMODE, when a windows client app attempts to set a *directory* archive bit, Samba just pretends the operation is successful even thought the archive bit is never actually set. However, if the user is NOT the owner then an ACCESS DENIED error is generated. This is obviously a bug, albeit a very subtle one but it does cause XCOPY to bomb out and Windows Profile Saving to Server to fail. A bug fix for this is vital as many stable server distros running samba do *not* use extended attribute mappings by default.
(In reply to comment #1) > This has nothing to do with ntlm_auth. Apologies, but I could not find a "Don't Know" option
As the cause of the issue is found, this is me too. I have this issue on a Debian etch server with samba 3.0.24-6etch4 and on a Debian etch server with my own backport version 3.0.25a-1~mc.1 BTW: I would guess this is an nmbd issue (I'm no allowed to change)
(In reply to comment #4) > BTW: I would guess this is an nmbd issue (I'm no allowed to change) Whoopps, not nmbd but smbd which is not selectable :(
I think is by design, but maybe the design choice should be revisited. Jeremy?
(In reply to comment #6) > I think is by design, but maybe the design choice should be revisited. > Jeremy? When this is by design, then why do windows explorer and xcopy respond different? Copying c:/dir/sub/file to //samba/share with xcopy (xcopy /s c:\sub \\samba\share) gives ACCESS DENIED, drag c:/dir and drop on //samba/share works :(
(In reply to comment #6) > I think is by design, but maybe the design choice should be revisited. > Jeremy? If by design, then why does it work okay for files? My understanding is that DOS FILE MODE is supposed to mean that, if the user has write access to file or folder, then he can modify file or folder attributes and ownership sould not enter into the equation.
> When this is by design, then why do windows explorer and xcopy respond > different? Actually, this may be a misperception. If you try to change directory archive bit in explorer, you will get an access denied message if you are not the owner. I think what happens with XCOPY and User-Profile Saving operations is that they try to change the archive bit in a given folder and the ACCESS DENIED error causes the entire operation to bomb out.
I think this bug can be fixed by the patch in bug #5202 I posted.
can one of you confirm that this is fixed in recent samba releases?
No Feedback from Fumiyasu and rvjcallanan. Closing this now hoping it's fixed.