Re: Unusual behaviour of veto files parameter on Samba 3.x using GNU/Linux Clients with 2.6.27 kernel

On Thu, 21 May 2009 07:51:01 -0700 (PDT)
Joseph Dacuma <[email protected]> wrote:

> 
> Hello Jeff!
> 
> > This sounds pretty clearly like a server-side problem.
> > Given that the
> > idea behind "veto files" is to hide certain files from the
> > client, the
> > server can't rely on a client being "cooperative". If it's
> > presenting
> > these files to the client at all, then the server is
> > broken.
> > 
> > My first suspicion would be that this is a samba bug that
> > is only
> > happening when unix extensions are enabled. You might want
> > to repeat
> > your tests on the linux clients, but this time mount with
> > '-o nounix'.
> > If the server starts behaving correctly with that, then I
> > suggest
> > filing a bug with this info at samba.org.
> > 
> > Cheers,
> > -- 
> > Jeff Layton <[email protected]>
> > 
> 
> First, my apologies with my initial post by failing to indicate that it is "not" the fault of the default Samba packaged by Debian on the first test case.
> 
> As for the problem, the nounix switch yeilds the desired result of files being vetoed. I tested it many times on both OpenSUSE and Mint clients. No traces of .iso,.exe,.dll,.pif files.
> 
> I also tried other means of accessing both shares without directly mounting them. These were done using Konqueror on OpenSuSE and Nautilus on Mint. Both consistently behaved as expected:
> 
> 1) Couldnt create/transfer files with the restricted pattern/extension from the client.
> 2) Restricted files that transferred on both shares via scp were not displayed when mounted with -o nounix, and accessed by Konqueror and Nautilus.
> 
> Any other tests you need to be performed before we call it a bug?
> 
> Kind regards,
> 
> Joseph
> 

No, I was pretty convinced that this was a samba bug from the get-go.
Feel free to file a bug at samba.org (or with the vendor who packaged
your samba package).

-- 
Jeff Layton <[email protected]>