Addendum:  Mounting as type "cifs" works fine:

  mount -t cifs //server/share /mnt -o username=user,password=sekrit

But "smbmount" with the same arguments does not.  (Well, the mount
succeeds.  But any attempt to actually access the share fails.)

So "cifs" works and "smbfs" does not.  Go figure.

This bug also occurs under FC1 with the latest samba rpm's.  It
appears to be a bug introduced between 3.0.2-7 and 3.0.7-2 as prior to
Oct 10 I was running 3.0.2-7 and the smbmounts worked as usual but
after Oct 10 when I updated to 3.0.7-2 it broke.

The strange thing is, shares on Windows 2000 Server still work fine,
but shares on XP Pro, using users that authenticate in the domain, are
all broken.  I'll see if I can narrow it down even further.

I manage a large number of servers/shares over many offices and this
problem popped up at all the previously-working sites after the update
to 3.0.7-2, so it definitely is not a file server issue.

Thanks for the workaround, I will try that out as an interim solution.

More info:

The cifs workaround doesn't work under FC1 as the stock FC1 kernels
don't appear to have cifs compiled in?  And "mount -t smbfs" has the
same bug so this leaves no workaround for FC1 with the new rpm's.

Also, by downgrading one samba rpm release at a time I've managed to
definitively nail the bug introduction to between 3.0.2-7 and 3.0.4-1.
 Interestingly enough that appears to be when there was a bit of an
rpm reorginization that shifted more stuff into samba from samba-common.

The plot thickens: more testing reveals the bug seems to occur ONLY on
networks running a Windows domain (ie: Windows Server).  The bug does
not seem to occur on non-domain Workgroup-based networks.  This would
explain why more people aren't complaining.

Can the original poster please confirm they are running a domain?

Yes, we are running a domain (under Windows NT 4, I am embarrassed to
say).

I recently upgraded our FC1 packages from
3.0.4-1.FC1 to 3.0.7-2.FC1. We are running
a Windows Domain on Windows 2003 Server. Before
upgrading everything was fine, afterwards I do
encounter this Bug.

I've seen the same thing with FC2.  If I mount with type "smbfs", it
works great for reading but fails to write.

If I mount with type "cifs", it works for both reading and writing,
though it is very slow for several minutes after the mount

With cifs, the touch command can create a file but reports:
    touch: setting times of `foo': Permission denied
Perhaps this is normal with smbfs as well, though I can't verify that
because writing doesn't work at all.

I am running into the same bug, but I am NOT running under a windows
domain.
I am using FC2 to connect to a Windows XP box running SP2.

I am able to connect to the share using smbclient, but I can not mount it.

I run the mount command and mount it to /mnt/myserver/c.  If I do an
ls -l in /mny/myserver I see:
drwxr-xr-x  1 root root 4096 Nov  2 15:16 c
drwxr-xr-x  2 root root 4096 Nov  2 14:21 d
[
If I go into 'c' and do an ls -l I get "ls: .: Permission denied"

If I go back to /mnt/myserver and do an ls -l I get:
?---------  ? ?    ?       ?            ? c
drwxr-xr-x  2 root root 4096 Nov  2 14:21 d
[

I'm having this very same problem while connecting to a windows 2003
file server with RHEL ES and WS 3.0 Update 4 (Latest) with all the
latest patches from RH.

This parameter in the policy of the server if DISABLED (by
recommendation of Samba and many people on the net):

Microsoft network server: Digitally sign communications (always)

Patrick Monfette

I have exactly the same problem.
Since samba > 3.0.2 smbmount results in permission denied.
The server is a Windows 2003 server / domain controller.

The client is RHEL 3.0 Update 4 (problem was the same in U3 as well)

I have submitted a support reqiest to redhat technical support on 29
Nov 2004, but so far no progress has been made on the case (Service
Request: 405604)

Alois Treindl

Patrick: I'm trying to understand what you said.  Are you saying that
if we disable an option/policy on the Windows Server that the problem
will go away?

No, just that I had to disable this policy because at first, I was not
even able to connect to the windows 2003 server, I had this error:

cli_negprot: SMB signing is mandatory and we have disabled it.
26595: protocol negotiation failed
SMB connection failed

Now, by disabling the above option, I am able to connect to the
server, but I'm not able to use it. This is a known problem with XP
and Windows 2003 and the version of Samba used under RHEL 3.0
(whatever update you use)

I heard that using CIFS resolves this also + the current problem we
have, but since the version of Samba that comes with RHEL 3.0 doesn't
support CIFS and that I cannot go away from supported RHEL by patching
to the latest version, I cannot solve this problem if RedHat doesn't
solve it. A very interesting circular queue without any output... :-)

Since I could reproduce this at will on one Server 2003 DC box I run
for testing at home, but could NOT reproduce it on another we have in
our Samba testing environement here, I set up another Server 2003
server in our Samba test environment.

With the newly-set-up server, we could not reproduce the behavior
prior to adding Domain Controller functionality, either before
applying ANY updates to the server, or after applying ALL available
security/etc updates to the server.

After adding the Domain Controller (AD) function to the new 2003
server we set up in our test environment, we are now able to reproduce
the behavior from Samba-3.0.9-1.3E.2 smbmount clients.

The AD was set up as a "new forest".  A DNS "subdomain" name was
created and delegated to the 2003 server in the parent domain's zone
file.  During setup of the AD, when it prompted for how to deal with
DNS, we told the wizard to set up the DNS service on the 2003 server
to handle the AD's DNS subdomain and configure localhost as a DNS server.

When prompted during setup of the AD how to set permissions, we chose
"Permissions compatible only with Windows 2000 or Windows Server 2003
operating systems".

---

So far, the changes made to security policy settings are:

BEFORE MAKING SERVER A DC:

Local Policies - Security Options - Microsoft Network Server -
Digitally Sign Communications (Always) - was already disabled (default
apparently)

Local Policies - Security Options - Domain member - digitially encrypt
or sign secure channel data (always) - Set to DISABLED (was enabled).

AFTER MAKING SERVER A DC:

- In Domain Controller Security Policy:
     Local Policies - Security Options - Microsoft Network Server -
Digitally Sign Communications (Always) - WAS enabled, turned OFF


The changes to security policies documented above were necessary just
to allow the Linux smbmount client to mount the share.  We will
conduct further research/testing to see if any further policy settings
can be made so that the mounts work properly.

Note also that I had opportunity to test a Red Hat Enterprise Linux 4
beta, which does have cifs filesystem support in the kernel and a
Samba built with the mount.cifs binary, and was able to confirm that
the mounted share works PROPERLY when mounted using -t cifs filesystem
type, even when mounting it from a 2003 Server that exhibits the bad
behavior when mounting via smbmount.  So it appears that mounting "-t
cifs"  will exist as an option in Red Hat Enterprise Linux 4. 

Thanks,
Vince

Well, in a way, I'm glad you were able to reproduce the problem and
confirm that is is solved in a new release and that CIFS is the
solution, those were things I was hoping to confirm.

I also had to make the same modification you did just to connect to
the share (Digitally Sign Communications (Always) - WAS enabled,
turned OFF) and now we're on the same page, able to connect, unable to
do anything else with the share...

I'll wait for your reponse on how to fix this (either on W2K3 or on
Linux) and if it is impossible, I guess a new version of the samba
packages will be delivered trough up2date so we can fix everyone
permanently.

Thanks, Patrick

That would be a new kernel rpm.  Once the mount succeeds, Samba's 
part of the "making smbfs work" process is done.  The rest is all in 
the kernel.  I'm redirecting this bug to the kernel maintainers. 

I have a service request open with redhat support for RHEL 3, 
request #405604 since 29 November 2004.
No progress has been made despite many exchanges between the support
engineer and me.

Now (on 25 January 2005) I have been informed, that
-quote-  only the Kernel 2.6.x included in RHEL4 will be able to
communicate properly with Windows2003. -end quote-

This means that Redhat is not supporting interoperability with Windows
2003 server (accessing windows shares) in Redhat Enterprise Linux 3.

I find this policy outrageous. Redhat calls this product 'enterprise
linux' but it cannot interoperate with a Windows2003 server!

(it could until samba 3.0.2 and was broken then, and nobody at redhat
seems to understand what went on or is willing to fix it)

This behavior is the result of default security policy settings on the
Windows system.  While the behavior seems to be most common with
Windows 2003 servers and 2003 Domain Controllers (DC's) in particular,
the behavior is at least theoretically possible on other types of
Windows systems which have the same security policy settings in effect.

You will need to make the following changes to Security Policy
settings on the Windows host.  Separate information is provided below
for normal servers or workstations which are not domain controllers,
and servers functioning in a DC role.


For workstations and non-DC servers:
---------------------------------------------------
Open the Local Security Policy tool and make the following changes:

  Local Policies - Security Options - Microsoft network client -
digitally sign communications (always) - DISABLED

  Local Policies - Security Options - Microsoft network client -
digitally sign communications (if server agrees) - DISABLED

  Local Policies - Security Options - Microsoft network server -
digitally sign communications (always) - DISABLED

  Local Policies - Security Options - Microsoft network server -
digitally sign communications (if server agrees) - DISABLED
---------------------------------------------------


For servers that have a DC role:
---------------------------------------------------

Open the Domain Controller Security Policy tool and make the following
changes:

  Local Policies - Security Options - Domain member - Digitally
encrypt or sign secure channel data always - ENABLED

  Local Policies - Security Options - Microsoft network client -
digitally sign communications (always) - DISABLED

  Local Policies - Security Options - Microsoft network client -
digitally sign communications (if server agrees) - DISABLED

  Local Policies - Security Options - Microsoft network server -
digitally sign communications (always) - DISABLED

  Local Policies - Security Options - Microsoft network server -
digitally sign communications (if server agrees) - DISABLED


Next, open the Domain Controller Security Policy tool and make the
following changes:

  Local Policies - Security Options - Microsoft network client -
digitally sign communications (always) - DISABLED

  Local Policies - Security Options - Microsoft network client -
digitally sign communications (if server agrees) - DISABLED

  Local Policies - Security Options - Microsoft network server -
digitally sign communications (always) - DISABLED

  Local Policies - Security Options - Microsoft network server -
digitally sign communications (if server agrees) - DISABLED

---------------------------------------------------

After making all of the changes, you will need to either run "gpupdate
/force" as a user with admin rights, or reboot the Windows system.  
Note, you should unmount the share from the Linux system before
rebooting the Windows host.  You should then be able to smbmount the
share and experience normal behavior with the share.

While smbmount is a userspace binary that belongs to the samba-client
RPM, it only sets up the filesystem mount with the remote host.  It is
the smbfs filesystem code in the Linux kernel which provides the
actual filesystem support.  The smbfs code in the upstream kernel
sources is fairly old and not currently maintained.  CIFS (Common
Internet Filesystem) is the more modern (and SMB-compatible)
filesystem, and should be used instead on systems using 2.6-series
Linux kernels.

When mounting Windows shares using the -t cifs mount option from a Red
Hat Enterprise Linux 4 system, the problematic behavior does not
occur, even when mounting the same shares that cause problems when
using the smbmount command because the Windows host has not had all of
the above security policy changes made.

NOTE: 2.4-series Linux kernels (ie, Red Hat Enterprise Linux 3 and
previous) do not contain support for the CIFS filesystem.  Therefore,
you must make the above-detailed changes to your Windows hosts for
smbmount to function properly.

Note, an article with this same information will also be published in
the Red Hat Knowledgebase.

Thanks, I will try.
I have a German windows 2003 server and have to translate, to find
these option si the German version.

You write  
Local Policies - Security Options - Microsoft network server -
digitally sign communications (if server agrees) - DISABLED

I presume you mean (if client agrees)
on two locations of your listing

Hi

you did the trick. many thanks.

Alois

Alois yes that was yet another typo.  I was trying to get the
information out as quickly as possible.  Thanks for pointing it out!

I just want to add that the site I was having the main problem at is
running Windows 2000 Server with AD on (not 2003!).  Also, smbmount
was working perfectly fine on the network until we updated the samba
packages.  After that it broke (with no other changes made).  After
downgrading back to older samba packages it worked perfectly again!

If the root of the problem is either a) kernel code or b) Windows
settings, then how come the symtpom is ONLY dependent on the samba
version???  That would indicate there is something that can be done in
the samba code to fix this.

This seems to go against what I'm reading above.

For the record, the Windows 2000 Server setup we have has keys that do
not match the paths you list above.  Perhaps they changed the layout
in 2003?  On mine the only option that is not "not defined" is:

Local Policies -> Security Options -> Digitally sign server
communication (when possible) -> Enabled  (the default, as I never
touched this before).

Also, on our XP Pro workstations I could not find the "Local Security
Policy tool" you mention.

Hi,

What I've found out about the recent samba versions, is that they
support smb signing and there's no way to turn it off.

So basically, samba (smbmount) tries and successfully negotiate smb
signing with the server and after that, it passes everything to the
kernel, but since the kernel isn't able to deal with smb signing,
mounting and authentification works perfectly (samba's part) but
browsing the share or doing anything else afterwards doesn't work
since the kernel doesn't know how to deal with this.

I actually made some recommendations to RedHat regarding this, one of
the recommendation is to remove smb signing from samba at compilation
time since their kernel doesn't support it and everything breaks
because of that (1 - Very easy but not very security conscious),
enable support for smb signing in the kernel (2 - Very much prefered
way) or have a way (manually by a command-line option or in the
configuration file) to disable smb signing in samba, particularly
smbmount (3 - and very less prefered way).

And by the way, you are right, this problem is not exactly a Windows
2003 problem, the fact is that Microsoft now turns on some stuff in
their policies, for security reasons, that they were not turning on in
the past (in Windows 2000 for instance) and that creates problems with
you have broken things like we have. You can replicate this kind of
behavior on a Windows 2000 server and Windows XP if you turn on
digitally sign server stuff everywhere in your policies. Those
policies are usually found under Control Panel -> Administrative Tools
-> Local Security Policies or Domain Controller Security Policies or
Domain Security Policies.

I also pointed out to redhat that having to turn off security settings
under Windows in order to let in the linux servers and workstations is
really not something to be proud of on the linux side and is certainly
not a good thing from a security perspective.

For your info, ir the last posts from RedHat in my trouble ticket with
them (since I have support because I bought RHEL):

---------
Agreed, the procedure does represent a workaround, by turning off
things on the Windows side that smbfs can't really deal with.

I wouldn't be able to say for sure, but I would suspect that the
prospect of Red Hat adding SMB signing support to the smbfs code in
the kernel would probably not be met with a great deal of fanfare. 
But if you haven't already, you may want to put the points you raised
in your last post in the Bugzilla and see what our developers say.
----------
One of our engineers mentioned posting a bug against the kernel for
this behavior.  I'll be touching base with him with the points you
raised.  It may be better to work from the smbmount end.
----------


That's it, probably the easy way out will be chosen, at least, we
could have a fix that works, not just a workaround...

Patrick

I thought I'd follow up on this issue:  I have finally upgraded the boxes I had
this problem on to FC3.  Using smbmount still fails as described above.  As
predicted, mount -t cifs works great.  So I no longer use smbmount -- easy solution!

I thought I'd mention that I noticed one oddity that I'm not sure was mentioned.
 smbmount works fine when mounting shares on the actual domain controller.  It
only seems to fail when mounting shares on non-server workstation (XP Pro)
systems that are on the domain.  I can't recall if I tested/noticed this when I
was running FC1, but I'm sure it must have been the same.

PS: I haven't changed a single thing on the domain controller or Windows boxes.
 The easiest fix is use mount -f cifs on FC3 and forget about smbmount.  A
solution that requires tweaks on XP workstation boxes is not a good fix as it
would be a pain to tweak 50 workstation boxes.

Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done
so).

Thanks.

Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.

2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

As SMBFS is unmaintained upstream, we're looking at deprecating it completely in
future Fedora releases in favour of CIFS which is actively maintained.  If CIFS
doesn't work for you with the latest update kernels, please open a new bug with
the details of the server you're trying to connect to. (What OS/service pack etc).

Closing as 'WORKSFORME' as bugzilla lacks a 'CLOSED->WORKAROUND' field.