I have a Hawking HNAS1 network attached storage that runs samba 2.0.7. No firmware updates are available for this device. It has one share. I can mount the share using mount.cifs and everything looks normal; all file permissions are as expected. I can create and remove directories, but cannot read or write files. Every attempt to access a file results in a "Permission denied" error. This behavior is the same whether the share is configured for open access (mounted with sec=none) or limited to user login. Share contents are readable and writable using smbclient, through the network browser capability in gnome and KDE, and from a W2K SP4 machine. umount.cifs works perfectly with a Trendnet TS-U200 NAS appliance running samba 2.2.8a. This problem is observed with the following client systems: Ubuntu 8.04, gnome, samba 3.0.28a Ubuntu 9.04, gnome, samba 3.3.2 Fedora 10, gnome, samba 3.2.11 Fedora 11, gnome, samba 3.3.2 PCLinuxOS 2009.2, KDE, samba 3.0.33 Slackware 12.2, KDE, samba 3.2.13 I have tried every mount.cifs option that seemed remotely connected to file permissions with no affect, including noperm as suggested by Jeff Layton recently in comment #11 of bug 2512. Since the share is accessible through smbclient and the network browsers, I presume this is a bug in mount.cifs, not the 2.0.7 server. Unfortunately, there is no way to view or modify the server settings on the HNAS1 other than the limited configuration provided through the web browser interface. In fact the only reason I know it is running 2.0.7 is the connect message from smbclient. Following is the content of /proc/cifs/DebugData from one client. 192.168.1.3 is the 2.0.7 server, 192.168.1.4 is the 2.2.8a server. Display Internal CIFS Data Structures for Debugging --------------------------------------------------- CIFS Version 1.55 Active VFS Requests: 0 Servers: 1) entry for 192.168.1.3 not fully displayed TCP status: 1 Local Users To Server: 1 SecMode: 0x2 Req On Wire: 0 Shares: 1) \\192.168.1.3\Share Mounts: 1 Type: NTFS DevInfo: 0x0 Attributes: 0x2b PathComponentMax: 128 Status: 0x1 type: 0 MIDs: 2) entry for 192.168.1.4 not fully displayed TCP status: 1 Local Users To Server: 2 SecMode: 0x2 Req On Wire: 0 Shares: 1) \\192.168.1.4\SD_MMC_c Mounts: 1 Type: NTFS DevInfo: 0x0 Attributes: 0xb PathComponentMax: 255 Status: 0x1 type: 0 MIDs: 2) entry for 192.168.1.4 not fully displayed TCP status: 1 Local Users To Server: 2 SecMode: 0x2 Req On Wire: 0 Shares: 1) \\192.168.1.4\CF_a Mounts: 1 Type: NTFS DevInfo: 0x0 Attributes: 0xb PathComponentMax: 255 Status: 0x1 type: 0 MIDs:
I doubt this is a mount.cifs bug. More likely a kernel problem if it's a bug at all. Is this still an issue with more recent kernels? If so, can you get a network capture per the instructions here and attach it to the bug? http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures
Created attachment 7439 [details] Network capture file
Created attachment 7440 [details] Terminal log file
The problem still exists as described on both Fedora 16 with the 3.3.0-8.fc16.x86_64 kernel and Ubuntu 11.10 with the 3.0.0-17-generic kernel. I created the network capture per the referenced directions and the gzipped capture file is attached along with a log file from the two terminal sessions I had open, the first for tcpdump and a second for the access test.
My this is an old server. It's still sending DOS error codes. This really looks like a problem with the server... Ok, in the capture you're authenticating anonymously to the server and then I see a successful directory create, and then when you go to create a file it returns ERRbadaccess. That error means "invalid open mode" and maps to -EACCES in POSIX land... Unfortunately, I'm not sure how to interpret that error and don't see anything particularly problematic with the call. It could occur for a lot of reasons. Is it possible to get a capture of a file being successfully created using something like smbclient that I could compare it with? Alternately, does this server have a way to run samba in debug mode? If so then getting a -d10 log from smbd might help point out what it doesn't like.
cc'ing Steve to get a second opinion... Do you see any problems with the create call we're sending here?
I ran the test using smbclient (version 3.6.3-78.fc16) as you suggested in comment #5 and was able to create a directory and write an empty file. I am attaching the terminal log and gzipped tcpdump output. Hopefully this helps. Jeff - There is probably no point in putting much effort into this bug. As you noted it is a very old server on fairly rare and no longer supported hardware. I have ample methods to access this NAS box without using mount.cifs so it is really just an annoyance, not a problem. Mike
Created attachment 7454 [details] Network capture file using smbclient for file creation
Created attachment 7455 [details] Terminal log file using smbclient for file creation
I was quite surprised to find this bug still being discussed and worked on, as the hardware in question is indeed old and forgotten. But I hit this very same bug over the weekend, as an academic exercise trying to mount an HNAS1 from the latest CentOS via cifs. My experience is similar to Mike. I can mount and unmount fine; ls shows the accurate contents of the drive after mounting. But I cannot access any files for reading nor writing, seeing the "Permission denied" message. One thing that seemed to work for me and may not have been tried by Mike is rmdir - I created an empty directory on the Windows side, and I -believe- I successfully removed it from CentOS. And, like Mike, in the course of flailing around I tried all the likely mount switches (perm, domain, force, ...) with no change, and no luck. One thing that struck me is that this may be down to the type of password that is expected (even though the share is set to no password). In the old days MS LanManager and NT had more than one password scheme, some encrypted and some clear (from deep memory). I wonder if the HNAS1 expects something different in the password field than is being supplied by Samba? And echoing Mike's last comment, this is simply an exercise for me, not a priority, so if the answer doesn't pop out it's no great loss. The HNAS1 can manage only a 200G drive maximum, so there are lots of modern 1T, 2T, 3T units to use seriously (grin). This is more along the lines of "Can it be made to work?" Thanks.
Ok, smbclient is doing something different here. It's using an OPEN_ANDX call whereas cifs.ko is using NT_CREATE_ANDX. The difference seems to be due to the different dialect selection at the beginning of the protocol negotiation. smbclient sends a bunch of dialects and the server selects "NT LANMAN 1.0". cifs.ko sends a fewer number of dialects and the server selects "NT LM 0.12". This is interesting since it _avoided_ that dialect when talking to smbclient. In any case, it's setting the CAP_NT_SMBS bit in its capabilities, so it's saying that it can support the call we're sending it... At this point, I'm going to go ahead and chalk this up to a server bug. It's possible that we're sending some problematic set of permissions (we are requesting GENERIC_WRITE here), but I'm not sure I understand why that'd be a problem. Perhaps we can revisit it later if more info comes to light...