[Samba] Symbolic links not visible on osx 10.10

[Ralph Böhme]

Hi!

On Mon, Jan 05, 2015 at 02:08:46PM +0100, Markus Doits wrote:
> I'm using the latest git 4.2.0 samba version (4.2.0rc4-GIT-93b73bf, to
> get latest vfs_fruit module). I noticed the following strange behavior
> with OSX clients (10.10.1, 10.10.2 beta):
> 
> When they connect using either smb 3.0 or 2.1 (verified on the server
> with `smbstatus` and the `version` column `SMB3_00` or `SMB2_10`
> respectively), symbolic links pointing at non existent files are not
> displayed in the client. So for example I have this folder structure
> 
> folder/
> folder/existent_file
> folder/symlink_existent --> existent_file # shows on the osx client
> folder/symlink_nonexistent --> nonexistent_file # hidden in osx client
> 
> When I try to remove the folder with `rm -rf` in the osx client it
> fails, because it removes all files but the sysmlink on the nonexistent
> file (`rm: cannot remove ‘folder/’: Directory not empty`). The folder
> shows up empty in the osx client, but on the server the symlink is still
> there.
> 
> When I switch back to the smb1 protocol by connecting with `cifs://` in
> the osx client (`smbstatus` shows version `NT1`), the symlink to the
> nonexistent file is displayed as a link and can be followed/deleted.
> 
> I cannot test it with a sane client (linux) atm, but I assume this is
> because of an implementation failure in the osx samba 2.1 and 3.0
> protocol. Is there any workaround to use the newer protocols but make
> symlinks behave like they should?
> 
> I already tried some options like
> 
> follow symlinks = yes
> wide links = yes
> unix extensions = no
> 
> (and different yes/no variations), but symbolic links to nonexistent
> files only show up when connecting with NT1 version.
> 
> For completeness, here is the share's config:
> 
> [Programs]
>         path = /server/shares/programs
>         valid users = some users
>         read only = No
>         force create mode = 0660
>         force directory mode = 0770
>         vfs objects = fruit # tried without fruit vfs, no change

on first reading I thought this sound like a bug in vfs_fruit, but
here you mention that this happens regardless of using
vfs_fruit. Right?

-Ralph

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt@sernet.de