The Samba-Bugzilla – Bug 12459
Share 'IPC$' has wide links and unix extensions enabled.
Last modified: 2017-02-06 19:58:28 UTC
We are running Samba 4.4.7 on a Solaris 10 i386 box. I have been seeing the
following warnings for some time despite having 'unix extensions = no' in our
smb.conf file and having no share named IPC$.
[2016/11/29 10:15:18.204486, 0] ../source3/param/loadparm.c:4402(widelinks_warning)
Share 'IPC$' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
I have been assuming that these messages were harmless, but yesterday a user who
uses such symbolic links had a problem with them not working. I found the log
for her machine filling up with these messages. After rebooting her Windows 7 PC
the links started working and the log messages stopped. I am thinking that after
the reboot she got a new smb process to serve her PC.I have added
'allow insecure wide links = yes' to our smb.conf file in the hope that this
will prevent problems in the future.
Following is our smb.conf file with most of the shares removed but including
the share that was being used when the problem happened.
max protocol = NT1
workgroup = adi
server string =
client ldap sasl wrapping = plain
require strong key = no
client ntlmv2 auth = no
client signing = auto
winbind sealed pipes = no
security = domain
load printers = no
printcap name = /etc/printers.samba
printing = sysv
guest account = nobody2
log file = /opt/local/samba4/var/logs/%h/log.%m
max log size = 150
password server = starfish2
passdb backend = tdbsam
socket options = TCP_NODELAY
dns proxy = no
dos filemode = yes
delete readonly = yes
name resolve order = bcast host
host msdfs = yes
msdfs root = yes
unix extensions = no
wide links = yes
lock directory = /var/samba/locks/%h
pid directory = /var/samba/locks/%h
include = /opt/local/samba4/etc/smb.conf.%h
netbios aliases = crayfish
#============================ Share Definitions ==============================
comment = User Directories
path = /home/users
browseable = yes
writable = yes
; inherit acls = yes
inherit permissions = yes
; guest ok = yes
She has a network drive mapped to:
'allow insecure wide links = yes' does not eliminate the problem.
As noted on the users mailing list, I can map a network drive to a share named IPC$ on our main server which has 'security=domain' specified. Another server which uses 'security=ads' does not offer such a share. I am going to try switching over to 'security=ads' on this server and see what happens.
> As noted on the users mailing list, I can map a network drive to
> a share named IPC$ on our main server which has 'security=domain'
> specified. Another server which uses 'security=ads' does not offer
> such a share. I am going to try switching over to 'security=ads'
> on this server and see what happens.
I turns out that 'security=domain' versus 'security=ads' is not what determines if share IPC$ exists. If 'max protocol = NT1' is specified then share IPC$ exists. If I comment out 'max protocol = NT1' and then restart Samba and also reboot the client PC then share IPC$ can not be mapped.Unfortunately we have to run our main server with 'max protocol = NT1' so I can't find out if removing it would eliminate the errors.