The symlink almost certainly points outside the root of the share it lives in. Samba refuses to follow such links by default, so from a client's perspective the link simply does not exist in that share. In your other share the target happens to sit inside the share's own directory tree, so the link resolves normally. This is not a permissions problem and the two links are not actually behaving differently on disk — it is Samba's policy on "wide links" that differs between the shares.
Why one share shows the link and the other does not
When a client connects to a Samba share, Samba only follows symbolic links if the resolved target remains within the share's configured path. A link whose destination escapes the share boundary is called a wide link, and wide links = no is the compiled-in default precisely because such links can let clients reach files the share was never meant to expose.
This explains the asymmetric behavior perfectly:
- In the ordinary share, the shared folder is presumably a subdirectory that contains (or is a sibling contained within) the target's tree, so the resolved target stays inside the share boundary and the link works.
- In the
[homes]share, the share root is the user's home directory. If the symlink points to, say, a data directory elsewhere on the disk, that target is outside/home/youruser, so Samba treats it as a wide link and hides it. Everything else in the home share displays fine because those are real files, not escaped symlinks.
On the server itself the link always works, since local processes do not go through Samba's share-boundary check.
Confirming the diagnosis
Compare the link's resolved target against the path declared for each share, and inspect the relevant global settings:
readlink -f /home/youruser/linkname
testparm -s | grep -iE 'path|wide links|unix extensions'
If readlink -f prints a location that is not underneath the [homes] share's path, and testparm confirms wide links is not set to yes, you have found the problem.
Fix option 1: allow wide links for that share
If you genuinely want clients to follow links that escape the share, enable it in /etc/samba/smb.conf:
[global]
allow insecure wide links = yes
[homes]
wide links = yes
Then restart the service:
sudo systemctl restart smbd
The extra allow insecure wide links = yes line is required because unix extensions are enabled by default on modern Samba, and while they are active Samba deliberately ignores wide links as a safety measure. Setting the global override lifts that guard so the per-share setting takes effect.
Understand the risk before doing this: any symlink inside that share that a client follows is resolved using the server-side user's permissions. If an attacker or careless user can create a link inside the share — for example via a writable upload directory — they could traverse to arbitrary readable locations on the server. Enable it only on shares where the contents are fully under your control.
Fix option 2 (recommended): use a bind mount instead
The cleaner solution avoids escaping links entirely. A bind mount makes the target directory appear as a real subdirectory of your home folder, so Samba sees an ordinary directory and the share boundary is never crossed:
sudo mount --bind /path/to/target /home/youruser/linkname
Remove or rename the symlink first, since the mount point must be an empty directory. To make the mount survive reboots, add an entry to /etc/fstab using the bind filesystem type:
/path/to/target /home/youruser/linkname none bind 0 0
Bind mounts have two advantages: no security settings need to be loosened, and the data appears identically to all clients regardless of which share they connect through. The trade-off is that mounts are a server-side construct — you maintain them in fstab rather than with a one-line ln -s command.
Preventing the problem in future
- Design shares so that anything you want visible lives physically under the share's
path; use bind mounts to graft in external trees rather than symlinks. - Document any share where you enable
wide links, and keep writable-by-everyone directories out of such shares. - After Samba upgrades, re-run
testparm -sto check that your wide-link and unix-extension settings still behave as expected, since defaults in this area have changed between Samba versions.
Frequently Asked Questions
Does Samba follow symlinks at all by default?
Yes, but only links whose target resolves inside the same share. Links pointing outside the share root are suppressed unless wide links are explicitly enabled for that share.
Why do I need allow insecure wide links in the global section?
Because unix extensions are on by default and Samba ignores the per-share wide links directive while they are active. The global override acknowledges the security implication and unlocks the per-share setting.
Is a bind mount safe to use with Samba?
Yes. Samba treats a bind-mounted directory as a normal part of the share tree, so no symlink policy applies and no extra server-side exposure is introduced.
The link shows up in the share but is unreachable — is that the same problem?
Not necessarily. If the link name appears but the target cannot be opened, check server-side file permissions and ownership first; the wide-link issue usually makes the link vanish from directory listings entirely.
Do I need to restart Samba after editing smb.conf?
Yes, restart smbd (for example with sudo systemctl restart smbd) for share-level changes like wide links to take effect.