When "veto files" is set to (for example): veto files = .AppleDouble/._*/.DS_store Copying already-existing files like "._foobar" will cause errors instead of just failing silently. For example: From *nix with smbclient: smb: \profile\Desktop\> put "._foobar" "._foobar" NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \profile\Desktop\._foobar Or from windows: Jun 2 13:35:18 WORKSTATION Userenv: DOMAIN\user: Windows cannot copy file C:\Documents and Settings\user\Desktop\._foobar to location \\SERVER\user\profile\Desktop\._foobar. Contact your network administrator. DETAIL - Cannot create a file when that file already exists. This will cause roaming profiles to abort unloading if you set the option on an existing setup. This can cause a bit of chaos when you choose to set this option on files like .DS_store to reduce clutter. Please grapeshot accordingly if duplicate/already fixed.
I can confirm this bug on a Gentoo Linux server with Samba 3.0.14. If a share is set up to veto dot-files, Mac OS X users will be unable to copy any files over to the share through the GUI; they will have to use the command line. This is because, when copying a file to a non-HFS file system, Mac OS X preserves the file's metadata by writing an invisible dot-file with the name "._<filename>". When the OS X attempts to write this during a copy to a Samba volume, Samba returns an error saying that the file name is bad. This also happens on Windows if the user tries copying a directory containing a dot-file (or a dot-file directly, if the user is viewing hidden files). I was debating with a co-worker as to whether this is really an OS issue or a Samba issue. Of course, Samba is acting exactly how it should. Vetoing files has the effect of denying both visibility AND access. Should the Samba server allow writes of files with vetoed names and then simply veto them once the write is done?