Between samba 4.16.4 and 4.17.5 the smb.conf 'veto files' parameter behaves differently. I also checked 4.17.8 and it does the same thing as 4.17.5. if smb.conf has veto files = /veto/ Say directory structure of share is public veto pss test1 test2 On 4.16.4 and earlier(for at least the last 14 years) ls /veto/pss/* shows a listing with test1 and test2 cd /veto/pss works On 4.17.5 and later smb: \> ls /veto/pss/* NT_STATUS_OBJECT_PATH_NOT_FOUND listing \veto\pss\* smb: \> cd /veto/pss cd \veto\pss\: NT_STATUS_OBJECT_PATH_NOT_FOUND On all versions the following fail, as they should smb: \> ls /veto NT_STATUS_NO_SUCH_FILE listing \veto smb: \> ls /veto/pss NT_STATUS_OBJECT_NAME_NOT_FOUND listing \veto\pss smb: \> cd /veto cd \veto\: NT_STATUS_OBJECT_NAME_NOT_FOUND Also On all versions ls /* shows listing without the veto dir I do not know if this change in behaviour is intentional but it was not mentioned specifically in the release notes. The only references in the 4.17 release notes to veto are:- BUG 15143: New filename parser doesn't check veto files smb.conf parameter BUG 15360: Setting veto files = /.*/ break listing directories.
Yes it's intentional. Nothing under a veto'd directory should be visible, else it rather defeats the point of veto files.
Oh dear, as it is intentional we will have to stop using 'veto files'. We have been using it for many many years to stop people casually browsing the share with Windows explorer and moving files around but still allowing our Windows programs to get at files and list files in sub directories. May I suggest you add something to the release notes about this as there may be other people doing the same thing. Maybe add a note to the smb.conf manual as well. I don't suppose there is another option to achieve the same thing is there? 'hide files' is no good as lots of Windows explorer users have show hidden files turned on.
Yes, it really is the way veto files was meant to work. Setting "veto files" really means such files/directories should not be seen to exist for clients. I'm afraid you have been taking advantage of a bug :-(.