[Samba] OS X client symlinks

Todd Thorson casatech19 at gmail.com
Tue Apr 16 18:33:53 UTC 2019


The parameter “unix extensions = yes” should  allow the specific behavior you want, however there may be some security risks - see the smb.conf man page.
Below are the changes I made to my smb.conf to get my samba server to emulate OSX SMB.  You may not need all of these since some defaults have changed between samba 4.3 to 4.8, but I don’t think they can hurt.  FYI I have submitted this to the sambawiki as a user doc for we Mac users ;-)

Best regards,

Todd

# smb.conf server parameters to use with Mac OSX clients
#
# NOTE - THIS IS NOT A COMPLETE SMB.CONF!!!

# check Samba version: smbd -V
# check build options: smbd -b
# check config: testparm
# check config including defaults: testparm -v

# NOTE - not all parameters may be valid for your version of Samba.
# NOTE - testparm will not validate vfs_fruit parameters.
# read smb.conf and vfs_fruit man pages for your version

# PREREQUISITES TO FUNCTION WITH OSX
#
[Global]
 min protocol = SMB2
# note - do not set a max protocol - Samba will negotiate highest
 ea support = yes

# NOT NEEDED WITH OSX
#
 disable netbios = yes
 dns proxy = no
 smb ports = 445
 name resolve order = host bcast

# ADD COMPATABILITY WITH OSX SMB
# adds alternate data streams (ADS) support
#
 vfs objects = catia fruit streams_xattr  

# SMB2+ AAPL EXTENSIONS
# file metadata - Unix mode, FinderInfo, resource fork size, permissions
#
 fruit:aapl = yes
 readdir_attr:aapl_rsize = yes
 readdir_attr:aapl_finder_info = yes
 readdir_attr:aapl_max_access = yes
 fruit:nfs_aces = yes

# OSX COPYFILE
#
 fruit:copyfile= yes

# STORE OSX METATDATA & RESOURCE FORK 
# Netatalk compat xattr & ._ AppleDouble File
#
 fruit:metadata = netatalk
 fruit:resource = file

# FILE LOCKING
# no cross protocol locking
#
 fruit:locking = none

# MAP NTFS ILLEGAL CHARS TO UNICODE
#
 fruit:encoding = private

# PERFORMANCE TWEAKS
#
 smb2 leases = yes
 kernel oplocks = no
 use sendfile = yes
 strict sync = yes
 sync always = no
 aio read size = 1
 aio write size = 1

# FILE CLEANUP
#
 delete veto files = true
 unix extensions = yes
 fruit:posix_rename = yes 
 fruit:model = MacSamba
 fruit:veto_appledouble = yes
 fruit:zero_file_id = yes
 fruit:wipe_intentionally_left_blank_rfork = yes 
 fruit:delete_empty_adfiles = yes 

# INCREASE R/W SIZES
# default with SMB2.1+ and LargeMTU (SMB, not TCP/IP)
 smb2 max read = 8388608
 smb2 max write = 8388608
 smb2 max trans = 8388608

# SPOTLIGHT
# change to yes with Gnome Tracker on server side
#
 spotlight = no 

# TIME MACHINE
# separate share on server
#
[TimeMachineBackup]
 vfs objects = catia fruit streams_xattr
 fruit:time machine = yes
# furnish value before uncommenting
#  fruit:time machine max size = SIZE <<<<<
 path = /shares/TimeMachineBackup
 browseable = yes
 writeable = yes
 create mask = 0600
 directory mask = 0700
 strict sync = yes
# recommend to not index Time Machine
#
 spotlight = no

##### END OF CHANGES

> On 16Apr 2019, at 09:49, Serhii Mozghovyi <bov216 at gmail.com> wrote:
> 
> I mean a Unix-style symlink as if created by "ln -s file link".
> 
>> If I create Unix symlink, Finder will open the file UNLESS I move the linked file - in this case Finder CANNOT find the original file - the symlink is broken .
> 
> In my case the Finder is able to open symlinks, this is not the problem. The problem is that they are real normal files from the point of view of a client FS, not symlinks.
> 
> This is important because those files are NodeJS modules and they contain some relative requires: require('../blah-blah.js'). If the module is a symlink, those relative paths are computed from the symlink target by NodeJS, not the symlink itself. So symlinks are followed, as it's called. That happens on my server (CentOS). But when I run the same Node script on Mac OSX client, it doesn't work because that .js file is not a symlink and it's not followed and consequently the paths are broken because of that.
> 
> 
> My samba server version is 4.8.3. "vfs_fruit", "vfs_catia" and "vfs_streams_xattr_init" are all present in Build options, as well as vfs_aio_fork_init, vfs_aio_pthread_init. In the Headers section, I see HAVE_AIO_H.
> 
> --
> Best regards,
> Serhii
> 
> 
> 
> On 4/13/19 9:27 PM, Todd Thorson via samba wrote:
>> When you say “real symlinks on OSX” do you mean an “alias” that Finder would create? Or a Unix-type symlink using the “ ln -s file link” command in Terminal?  A Finder alias is not the same as a Unix-type symlink.
>> My NAS runs Debian Linux with version 4.3.11 of smbd; my clients are all OSX Mojave.
>> If I create an alias using Finder on the NAS, it behaves like a normal alias in OSX UNLESS I move the original file on the NAS - in this case, Finder can find the original file, but will not open it unless I select “Show Original”.
>> If I create Unix symlink, Finder will open the file UNLESS I move the linked file - in this case Finder CANNOT find the original file - the symlink is broken .
>> What version of samba do you have?  smbd -V on my NAS
>> Do you have vfs_fruit, vfs_catia & vfs_streams_xattr compiled in?  smbd -b on my NAS
>> Check also for the HAVE_AIO_XXX  in the Defines and vfs_aio_xxx in the Build Options.
>> What is your smb.conf?




More information about the samba mailing list