The context

From a Mac running Mountain Lion, a share "Multimedia" served by QNAP NAS is mounted as root via SAMBA in the Finder. Let's say I create a symbolic link of a directory on the NAS such as:

[/share/Multimedia] # ln -s /share/MD0_DATA/Multimedia/test/ ./folder/symlink     

It works:

[/share/Multimedia] # ls -la folder
lrwxrwxrwx  1 admin  administ  34 Oct 14 19:24 symlink -> /share/MD0_DATA/Multimedia/test//

I can also mv and cp files without problems to and from symlink when logged on the NAS.

This is the situation on the client-side, a Mac running 10.8.2:

client:~ myself$ id
uid=501(myself) gid=20(staff) groups=20(staff),401(com.apple.access_screensharing),

Strangely, the client doesn't recognize symlink as such; it's a normal directory instead (please note that according to the output I have rwx permissions):

client:folder myself$ ls -la
drwx------  1 myself  staff  16384 18 Okt 23:25 symlink

The same happens in the Finder, where the folder symlink doesn't appear as an alias, but as a normal folder.

I can cd into symlink and I can also read files in it without problems. The same in the Finder.

The problem

If I try to write (mv or cp) a file into symlink on the client-side, it fails:

 client:folder myself$ mv test.txt symlink/
 mv: rename test.txt to symlink/test.txt: No such file or directory

Likewise, any attempt to move or copy a file into symlink via drag-n-drop in the Finder returns the following error:

The operation cannot be completed because one or more required items cannot be found. (Error code = -43).

(Moving/copying a file from symlink to another location on the NAS works just fine.)

Here's the output of a write operation in the Terminal:

 client:symlink myself$ touch text.txt
 touch: text.txt: Permission denied

Interestingly, I can successfully delete files which are already present:

 client:symlink myself$ ls -la
 total 64
 drwx------  1 myself  staff  16384 18 Okt 23:51 .
 drwx------  1 myself  staff  16384 18 Okt 23:48 ..
 -rwx------  1 myself  staff      5 18 Okt 23:51 text.txt
 client:symlink myself$ rm text.txt 
 client:symlink myself$ ls -la
 total 64
 drwx------  1 myself  staff  16384 18 Okt 23:56 .
 drwx------  1 myself  staff  16384 18 Okt 23:48 ..

I am really at loss on how to diagnose and solve this problem.

The relevant Apple kb states that Error -43 can have three causes:

  • Illegal characters (none there)
  • Permissions (permissions seem fine, see the ls -la output above. I mount the share with the admin account of the NAS and I am logged in as an admin on my Mac client.)
  • Non-existent share point (the share exists and works well otherwise)

Additional informations

Here's some more info for troubleshooting:

The global options in /etc/smb.conf on the NAS are set as follows:

passdb backend = smbpasswd
workgroup = WORKGROUP
security = USER
server string =
encrypt passwords = Yes
username level = 0
map to guest = Bad User
null passwords = yes
max log size = 10
os level = 20
preferred master = no
dns proxy = No
smb passwd file=/etc/config/smbpasswd   
username map = /etc/config/smbusers
guest account = guest
directory mask = 0777
create mask = 0777
oplocks = yes
locking = yes
disable spoolss = yes
load printers = no
force directory security mode = 0000
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/
delete veto files = yes
map archive = no
map system = no
map hidden = no
map read only = no
deadtime = 10
use sendfile = yes
display charset = UTF8
unix extensions = no
store dos attributes = yes
client ntlmv2 auth = yes
dos filetime resolution = no
min receivefile size = 4096
case sensitive = auto
domain master = auto
local master = yes
inherit acls = yes
wide links = yes
follow symlinks = yes
wins support = no
force unknown acl user = yes
template homedir = /share/homes/DOMAIN=%D/%U
domain logons = no

The specific options:

comment = System default share
path = /share/MD0_DATA/Multimedia
browsable = yes
oplocks = no
ftp write only = no
public = yes
invalid users =
read list = @"everyone","gast"
write list = "admin","guest"
valid users = "root",@"everyone","admin","guest","gast"
inherit permissions = yes

The logs on the client's side don't say much:

/private/var/log/system.log (which includes kernel.log since 10.8) shows up occasional entries like:

 Oct 18 22:13:43 client kernel[0]: smb_iod_reconnect: Reconnected share MULTIMEDIA with server qnap-SAMBA._smb._tcp.local

And /private/var/log/samba/ doesn't exist on my system.

Any help is much appreciated.

  • wondering about the ls -ld /share/MD0_DATA/Multimedia/test/ command result. So, what is the permission of the directory where the symlink points.
    – clt60
    Oct 19, 2012 at 14:37
  • @jm666 drwxrwxrwx 2 admin administ 4096 Oct 19 21:12 test/.
    – DBK
    Oct 19, 2012 at 19:18
  • @jm666: actually, ln -s /share/MD0_DATA/Multimedia/test/ etc. seems to be the wrong syntax (note the trailing slash at the end). However, ln -s /share/MD0_DATA/Multimedia/test etc. doesn't change the situation.
    – DBK
    Oct 19, 2012 at 20:26
  • the last thing what comes to my mind - try relative symlink path. So, cd /share/MD0_DATA/Multimedia/folder; ln -s ../test ./symlink. Probably not helps, but haven't another idea and maybe a export somewhat messing up absolute paths by the client view...
    – clt60
    Oct 20, 2012 at 20:08
  • Well, now you've said both "I can also mv and cp files without problems to and from symlink" and "If I try to write (mv or cp) a file into symlink, it fails" so I'm confused.
    – Old Pro
    Oct 20, 2012 at 21:52

1 Answer 1


In your configuration, you have unix extensions = no which is fine, but that is why symbolic links on the server are showing up as folders and not aliases. In this mode the server resolves the symbolic links and the client never sees them. If the client tries to create a symbolic link, the server actually generates an alias file, not a host-OS symbolic link. Reasons for this include security (preventing someone from getting access to /etc/passwd on the server by creating a symbolic link to it) and client compatibility, as OS X and Windows and Unix have slightly different ideas about what constitutes a symbolic link but they pretty much agree on what is a directory or a file.

Permissions issues with SAMBA are complex, so it's not clear that you do not have a permissions issue. Likewise symbolic like resolving is complex, so it is not clear that what you are doing should, in theory work, and there's always the possibility of a bug (most likely in the SAMBA server).

When accessing a SAMBA server from a Mac, these identities and permissions are involved:

  • The Mac User you are logged into the Mac as
  • The SAMBA user you are logged into the SAMBA server as
  • The SMABA server host OS user you get converted to
  • Unix-style file permissions
  • For NTFS and HFS+, associated file-system ACLs

So even though you have provided a lot of information, it's still not clear that you are not having permissions problems. The fact that you can mv and cp on the server (using what account?) does not mean you do not have a permissions problem preventing you from doing it on the client (using what accounts and with what effective account on the server?).

If the server is supporting ACLs and since you have options like inherit permissions = yes and inherit acls = yes set there could be some kind of ACL problem that is only allowing read access to directories accessed via symbolic links. There are several other avenues of investigation based on the server configuration.

I would really expect you should be able to find more information in the SAMBA server logs than you have communicated. They should give you a much better sense of exactly what is being denied.

For what it is worth, I tried to duplicate your setup using an Ubuntu 12.04 host as the SAMBA server and could not reproduce your problem. Symbolic links worked for me as expected.

  • Thanks for your explanation! The permission levels are more complicated than I thought. I understand now why permissions might be an issue - didn't think about ACLs at all. While I "solved" my problem with a workaround (creating the symlinks on the client-side), I will go the route of trial and error and modify the settings as well as checking the different permissions levels in order to get a better understanding of the whole architecture. Here's your +50 :)
    – DBK
    Oct 23, 2012 at 22:10
  • BTW, I took a look at the SAMBA server log while recreating the error, but nothing gets logged (that might have to do with some verbosity setting?)…
    – DBK
    Oct 23, 2012 at 22:14
  • [~] # tail -f /var/log/log.smbd [2012/10/24 00:00:06, 0] smbd/server.c:1329(main) smbd version 3.5.2 started. Copyright Andrew Tridgell and the Samba Team 1992-2010 [2012/10/24 00:00:09.447243, 1] smbd/service.c:1073(make_connection_snum) client (***.***.***.***) connect to service Multimedia initially as user admin (uid=0, gid=0) (pid 28255) [2012/10/24 00:00:17.518605, 1] smbd/service.c:1073(make_connection_snum) [2012/10/24 00:03:06.528095, 0] smbd/server.c:313(remove_child_pid) Could not find child 28314 -- ignoring
    – DBK
    Oct 23, 2012 at 22:15
  • @DBK I would disable ACLs unless you really need them. Under Ubuntu there were separate SAMBA logs for each client on the server, so look for those. Maybe increase the debugging log level of your server if there's no more info than what you posted. What is the OS of your server? What file system is the server using?
    – Old Pro
    Oct 23, 2012 at 22:27
  • Interesting, thanks. "unix extensions = no" in [Global] did the trick under an answer to a question in Ask Ubuntu, Permissions issue with symlinks over samba. Oct 23, 2012 at 23:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .