From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 Description of problem: From a root shell, I run: smbmount //server/share /mnt -o username=user,password=sekrit This command succeeds. But when I try to "ls /mnt", I get "Permission denied". Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Use "smbmount" to mount a share. 2. Try to access the share. 3. There is no step 3. Actual Results: "Permission denied" Expected Results: Access to the share Additional info: The same thing happens if I pass "selinux=0" as a boot-time parameter to the kernel. Also, this works fine from my RedHat 9 workstations, so I am pretty sure this is not a problem with my file server.
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.