Hello, 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 fruit:encoding = native Thanks for any help Markus
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 changeon 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 at sernet.de
Hi Ralph, On 05.01.15 15:00, Ralph B?hme wrote:>> [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?Yeah, just tested it once again to be sure - completely removing the `vfs objects` line. No change :-( One more observation: When creating a link in the osx client, it creates a file with some content in the share (no *real* symbolic link), so when I type the following in the osx client console it shows the link: ln -s non_existent linkname But on the server, `linkname` is actually a file with some weird content ... # cat linkname XSym 0012 08bcb178594050dcd60506a138b8c14c non_existent Looks like a candidate for the vfs_fruit module (translate symbolic links?!)? (tested it with vfs_fruit and without). Markus
On Mon, Jan 05, 2015 at 02:08:46PM +0100, Markus Doits wrote:> Hello, > > 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 > fruit:encoding = nativeCan you get debug level 10 logs + wireshark traces of the failing and success case please, then log a bug at bugzilla.samba.org. Thanks ! Jeremy.
Since I do not see my last messages in the samba mail archive (I replied myself), here's the last one I sent with some more information (so hopefully they arrive now for everybody?): I just found out this is not only happening on the osx clients by mounting the share on the server: All this below happens on an linux arch server mounting the own share: mount //ip.addr/Programs ./tmp -o vers=3.0 --> non existent symlinks do not show up --> cannot create symbolic links ("operation not supported") mount //ip.addr/Programs ./tmp -o vers=2.1 --> non existent symlinks do not show up --> cannot create symbolic links ("operation not supported") mount //ip.addr/Programs ./tmp -o vers=1.0 --> non existent symlinks show up ---> links are created as real links I noticed the mount output shows `nounix` when connecting with 2.1 and 3.0: //ip.addr/Programs on /mnt/tmp type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=markus,domain=OFFICE,uid=0,noforceuid,gid=0,noforcegid,addr=ip.addr,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=1048576,wsize=1048576,actimeo=1,user=markus) This is done automatically, I have no idea how to remove it. (-o unix, -o nounix=0 give an error) So not only happening on osx client ... :-( Is this maybe per protocol? Samba protocol 2.1 and 3.0 not being able to use *real* symbolic links? Markus