Samba, Symlinks and unix extensions

English Network/Internet
1

Hi all,

I have a directory shared with Samba. I am connecting to it with my Mac. In this directory I created a symbolic link to another directory. When I try with the command line, it follows the symlink fine.
I added the following to my /etc/samba/smb.conf


[global]
unix extensions = no
[someshare]
follow symlinks = yes
wide links = yes

However, the log says

Share ‘someshare’ has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.

And when I try to click on the symlink, the Finder thinks it’s an alias pointing to a local dir that I can’t find on my Mac.

Why does samba chose to ignore the unix extensions = no line in the smb.conf file?

smbd -V
Version 3.6.7-48.12.1-2831-SUSE-SL12.2-x86_64

fdisk -l


Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000dd094


   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048     4208639     2103296   82  Linux swap / Solaris
/dev/sda2   *     4208640    46153727    20972544   83  Linux
/dev/sda3        46153728  1953523711   953684992   83  Linux

df
Filesystem     1K-blocks      Used Available Use% Mounted on
rootfs          20641788   7062368  12530796  37% /
devtmpfs         1016868        36   1016832   1% /dev
tmpfs            1023692         0   1023692   0% /dev/shm
tmpfs            1023692       352   1023340   1% /run
/dev/sda2       20641788   7062368  12530796  37% /
tmpfs            1023692         0   1023692   0% /sys/fs/cgroup
tmpfs            1023692       352   1023340   1% /var/run
tmpfs            1023692       352   1023340   1% /var/lock
tmpfs            1023692         0   1023692   0% /media
/dev/sda3      938719072 894150340  26448724  98% /home

cat /etc/fstab
/dev/disk/by-id/ata-WDC_WD10EACS-00D6B1_WD-WCAU44133510-part1 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-WDC_WD10EACS-00D6B1_WD-WCAU44133510-part2 /                    ext4       acl,user_xattr        1 1
/dev/disk/by-id/ata-WDC_WD10EACS-00D6B1_WD-WCAU44133510-part3 /home                ext4       acl,user_xattr        1 2
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
2

On 1/18/2013 8:06 AM, ShaolinSatellite wrote:
>
> Hi all,
>
> I have a directory shared with Samba. I am connecting to it with my
> Mac. In this directory I created a symbolic link to another directory.
> When I try with the command line, it follows the symlink fine.
> I added the following to my /etc/samba/smb.conf
>
> Code:
> --------------------
>
> [global]
> unix extensions = no
> [someshare]
> follow symlinks = yes
> wide links = yes
> --------------------
>
>
> However, the log says
>> Share ‘someshare’ has wide links and unix extensions enabled. These
>> parameters are incompatible. Wide links will be disabled for this share.
>
<snip>
>
> --------------------
>
>
ShaolinSatellite;

Have you restarted smbd since editing /etc/samba/smb.conf? The [Global] section
of smb.conf is only read when smbd starts.

Could there be a typo? What does the following command give?


testparm -vs | grep unix

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

3

Please read this. It looks like both should be yes for symlinks to work.
**
unix extensions (G)**

This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by supporting features such as symbolic links, hard links, etc… These extensions require a similarly enabled client, and are of no current use to Windows clients.Note if this parameter is turned on, the wide links parameter will automatically be disabled. See the parameter allow insecure wide links if you wish to change this coupling between the two parameters.

Default: *unix extensions = yes *

follow symlinks (S)

This parameter allows the Samba administrator to stop smbd(8) from following symbolic links in a particular share. Setting this parameter to no prevents any file or directory that is a symbolic link from being followed (the user will get an error). This option is very useful to stop users from adding a symbolic link to /etc/passwd in their home directory for instance. However it will slow filename lookups down slightly.This option is enabled (i.e. smbd will follow symbolic links) by default.

Default: *follow symlinks = yes *

Further the default is such that for Yes, they both may be omitted.

I have a couple of blogs on Samba you can read here:

Samba S.W.A.T. - Samba Web Administration Tool Setup for openSUSE: https://forums.opensuse.org/blogs/jdmcdaniel3/samba-swat-samba-web-administration-tool-setup-opensuse-76/

AND

SWAT - Samba Web Administration Tool - Setup & Creation Script - 1.04: https://forums.opensuse.org/blogs/jdmcdaniel3/swat-samba-web-administration-tool-setup-creation-script-1-03-105/

And to Edit that smb.conf file directly, have a look here:

SYSEdit - System File Editor - Version 1.50: https://forums.opensuse.org/blogs/jdmcdaniel3/sysedit-system-file-editor-version-1-00-60/

Thank You,

4

On 1/18/2013 10:06 PM, jdmcdaniel3 wrote:
>
> ShaolinSatellite;2519514 Wrote:
>> Hi all,
>>
>> I have a directory shared with Samba. I am connecting to it with my
>> Mac. In this directory I created a symbolic link to another directory.
>> When I try with the command line, it follows the symlink fine.
>> I added the following to my /etc/samba/smb.conf
>>>
> Code:
> --------------------
> > >
> > [global]
> > unix extensions = no
> > [someshare]
> > follow symlinks = yes
> > wide links = yes
> --------------------
>>>
>>
>> However, the log says
>>
>>
>> And when I try to click on the symlink, the Finder thinks it’s an
>> alias pointing to a local dir that I can’t find on my Mac.
>>
>> Why does samba chose to ignore the unix extensions = no line in the
>> smb.conf file?
>>
<snip>
>>>
>
> Please read this. It looks like both should be yes for symlinks to
> work.
>
> UNIX EXTENSIONS (G)
> This boolean parameter controls whether Samba implements the CIFS
> UNIX extensions, as defined by HP. These extensions enable Samba to
> better serve UNIX CIFS clients by supporting features such as
> symbolic links, hard links, etc… These extensions require a
> similarly enabled client, and are of no current use to Windows
> clients.Note if this parameter is turned on, the ‘wide links’
> (http://localhost:901/swat/help/manpages/smb.conf.5.html#WIDELINKS)
> parameter will automatically be disabled. See the parameter ‘allow
> insecure wide links’ (http://tinyurl.com/b3rbgb4) if you wish to
> change this coupling between the two parameters.
>
> Default: --unix extensions- = yes -
>
> FOLLOW SYMLINKS (S)
> This parameter allows the Samba administrator to stop ‘smbd(8)’
> (http://localhost:901/swat/help/manpages/smbd.8.html) from following
> symbolic links in a particular share. Setting this parameter to no
> prevents any file or directory that is a symbolic link from being
> followed (the user will get an error). This option is very useful to
> stop users from adding a symbolic link to /etc/passwd in their home
> directory for instance. However it will slow filename lookups down
> slightly.This option is enabled (i.e. smbd will follow symbolic links)
> by default.
>
> Default: --follow symlinks- = yes -
>
> Further the default is such that for Yes, they both may be omitted.
<snip>
>
> Thank You,
>
>

You need the parameter, wide links, turned on to follow links outside the shared
file system. For security reason, this has defaulted to off since Samba version
3.5.0. For a discussion of the security problem with wide links on see:

Notice that in the above article, Unix clients resolve symbolic links locally.
Since the MAC is Unix based, that may be why the MAC is resolving the links
locally. ( I had not thought about that in my first post.)

From the manual for smb.conf:
http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html

wide links (S)
This parameter controls whether or links in the UNIX file system may be followed
by the server. Links that point to areas within the directory tree exported by
the server are always allowed; this parameter controls access only to areas that
are outside the directory tree being exported.

Note: Turning this parameter on when UNIX extensions are enabled will allow UNIX
clients to create symbolic links on the share that can point to files or
directories outside restricted path exported by the share definition. This can
cause access to areas outside of the share. Due to this problem, this parameter
will be automatically disabled (with a message in the log file) if the unix
extensions option is on.

Default: wide links = no

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

5

Alright, thanks for your help.
I will share the directory separately rather than using symlinks.

6

You are very welcome for the help and let us know if we can be of further service to you.

Thank You,

7

On 1/20/2013 2:36 PM, ShaolinSatellite wrote:
>
> Alright, thanks for your help.
> I will share the directory separately rather than using symlinks.
>
>
ShaolinSatellite;

Did you run “testparm” as in my first post? What did it return? The error
message sounds to me like you have (had?) unix extensions enabled for some
reason. All I can think of are:

  1. You edited the wrong copy of smb.conf.
    (The correct file is: /etc/samba/smb.conf)

  2. You have a typographical error in your entry for unix extensions.

  3. You have the parameter unix extensions entered twice. Once off and a second
    time on.

Anyway, IMHO you are better off using separate shares rather than relying on links.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

8

First, apologizes to bother you, long time after the last post. I did read the different books I have concerning Samba and strangely all the books are saying that wide links and follow symlinks are “share scope”. But technically I had only good results with symbolic links only if I put unix extensions = No follow symlinks = Yes wide links = Yes In the GLOBAL section. My question is the following: what the setting of “unix extensions” to “no” have as consequences ? If this “option” is set to “yes” by default there must be a reason, I did not yet find any answer. When setting wide links to “Yes” and unix extension to “Yes” leads to a conflict and the Samba server throws a warning. What “unix extensions” does ?

9

These are the descriptions found for each:

UNIX extensions (G)

This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by supporting features such as symbolic links, hard links, etc... These extensions require a similarly enabled client, and are of no current use to Windows clients.

Note if this parameter is turned on, the wide links parameter will automatically be disabled.

See the parameter allow insecure wide links if you wish to change this coupling between the two parameters.

    Default: unix extensions = yes

**allow insecure wide links (G)
**
In normal operation the option wide links which allows the server to follow symlinks outside of a share path is automatically disabled when unix extensions are enabled on a Samba server. This is done for security purposes to prevent UNIX clients creating symlinks to areas of the server file system that the administrator does not wish to export.

Setting allow insecure wide links to true disables the link between these two parameters, removing this protection and allowing a site to configure the server to follow symlinks (by setting wide links to "true") even when unix extensions is turned on.

If is not recommended to enable this option unless you fully understand the implications of allowing the server to follow symbolic links created by UNIX clients. For most normal Samba configurations this would be considered a security hole and setting this parameter is not recommended.

This option was added at the request of sites who had deliberately set Samba up in this way and needed to continue supporting this functionality without having to patch the Samba code.

    Default: allow insecure wide links = no

smb encrypt (S)

This is a new feature introduced with Samba 3.2 and above. It is an extension to the SMB/CIFS protocol negotiated as part of the UNIX extensions. SMB encryption uses the GSSAPI (SSPI on Windows) ability to encrypt and sign every request/response in a SMB protocol stream. When enabled it provides a secure method of SMB/CIFS communication, similar to an ssh protected session, but using SMB/CIFS authentication to negotiate encryption and signing keys. Currently this is only supported by Samba 3.2 smbclient, and hopefully soon Linux CIFSFS and MacOS/X clients. Windows clients do not support this feature.

This controls whether the remote client is allowed or required to use SMB encryption. Possible values are auto, mandatory and disabled. This may be set on a per-share basis, but clients may chose to encrypt the entire session, not just traffic to a specific share. If this is set to mandatory then all traffic to a share must must be encrypted once the connection has been made to the share. The server would return "access denied" to all non-encrypted requests on such a share. Selecting encrypted traffic reduces throughput as smaller packet sizes must be used (no huge UNIX style read/writes allowed) as well as the overhead of encrypting and signing all the data.

If SMB encryption is selected, Windows style SMB signing (see the server signing option) is no longer necessary, as the GSSAPI flags use select both signing and sealing of the data.

When set to auto, SMB encryption is offered, but not enforced. When set to mandatory, SMB encryption is required and if set to disabled, SMB encryption can not be negotiated.

    Default: smb encrypt = auto

** wide links (S)**

This parameter controls whether or not links in the UNIX file system may be followed by the server. Links that point to areas within the directory tree exported by the server are always allowed; this parameter controls access only to areas that are outside the directory tree being exported.

Note: Turning this parameter on when UNIX extensions are enabled will allow UNIX clients to create symbolic links on the share that can point to files or directories outside restricted path exported by the share definition. This can cause access to areas outside of the share. Due to this problem, this parameter will be automatically disabled (with a message in the log file) if the unix extensions option is on.

See the parameter allow insecure wide links if you wish to change this coupling between the two parameters.

    Default: wide links = no

Thank You,

10

I’ve encountered a problem with wide symlinks in Samba 4.1 under Open Suse 13.2, migrating from a Samba 3.0 installation set up in 2006. On that system, “insecure” wide links were later needed because of unbalanced partitioning that meant that the home partition became too small.

Although there is scope in the new system to avoid the need to copy the same arrangement from the old server, it seemed wise to start with that arrangement, and tidy it up later, so that the migration would be as seamless as possible. However, even with the most relaxed settings (follow symlinks=yes, wide links=yes, allow insecure wide links=yes) symlinks are not working as expected in the new environment.

The result is that rsync-ing with symbolic links being followed instead of preserved causes the home directories to be copied to two locations. This may not be a problem but, because some of the home folders have group access, I cannot be sure that the link targets can safely be removed from the migrated system.

11

Probably better if you start a new thread, instead of bringing up a post from 2013. Things have changed drastically since that year.

12

@frankthynne

It is by pure chance that someone found this thread of you. It is not very productive when you hang your problem at the end of such an old thread. Almost nobody will be subscribed to it. Also it is almost impossible that your problem is exactly the same as discussed in this thread, were it only for the time laps (as mentioned above.

So, to make your problem better vissible to your fellow openSUSE users here, start e new thread, with a title that contains keywords of your problem. The best way to advertise it.

This thread will be CLOSED to avoid further confusion.