Bug 12459 - Share 'IPC$' has wide links and unix extensions enabled.
Summary: Share 'IPC$' has wide links and unix extensions enabled.
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.4.7
Hardware: x64 Solaris
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-02 17:04 UTC by Tom Schulz
Modified: 2020-10-03 00:27 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Schulz 2016-12-02 17:04:20 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.

[global]
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 ==============================

[users]
   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:
\\server\users\her-name
Comment 1 Tom Schulz 2016-12-27 19:22:13 UTC
'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.
Comment 2 Tom Schulz 2017-02-06 19:58:28 UTC
> 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.
Comment 3 Björn Jacke 2020-10-03 00:27:40 UTC
I don't see such a problem here, please check with 4.13 again if the problem that you see persists. If you still see the issue, please file a new bug report with a slightly more compact problem  description.