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?