Lost access to our CIFS Server with Lion

Having the 'exact' same issue here with a NexentaStor installation, and it's holding up the whole deployment. Unfortunately, thus far 10.7.2 11C57 does not seem to address this issue in the slightest. Not looking good...

Many bad words, spoken in rapid succession.

This isn't good...since we really can't keep putting off the migration for a handful of people, looks like we'll have to wait for Apple to fix it, and put up with degraded functionality for the folks with 10.7.

The biggest problem is that new Macs are coming with 10.7, though fortunately we haven't had any of the 10.7-only MBA's show up, we can always downgrade the desktops to 10.6.

Several co-workers and I have been working with Apple on this issue since shortly after Lion came out. If your organization runs a network security device such as IBM ISS, that might be what is interfering with CIFS connections from Lion. After a lot of investigation, including tracing individual network packets, we find that the smb2 implementation on Lion appears to mimic a known Windows vulnerability that first surfaced in 2009. See

http://www.iss.net/security_center/reference/vuln/SMB_Negotiate_ProcessID_Exec.h tm for details. I have no idea why smbs2 on Lion does this, but it is sending traffic through our network with the same signature as this Windows vulnerability. Since our network security appliance blocks traffic with that signature, it blocks Lion's smb2 requests. We were able to verify this today and I have made Apple aware of this through official channels. If you are having this problem on a network where you have a network security appliance in the mix, try putting it into passthrough mode for a minute or two and attempt to mount your CIFS volume, and see if that works. If so, feel free to write to me privately at stan@temple.edu and I will be glad to give you the Apple case number so you can make Apple aware that your site is also experiencing this problem.

Just tried 10.7.2 11C73, which appears to be the GM build. Looks like 10.7.2 isn't going to fix this guys (although it does fix a few other minor bugs which I'll be happy to be rid of).

Stan, just to let you know I'm encountering it in my environment with both test appliance and host on the same subnet/vlan, not even a routed interface between them. So I highly doubt that your ISS is the only thing holding up your end (although it would certainly contribute to it).

As noted before by someone else, even with the permissions jacked up I seem to be able to execute copies etc via terminal just fine. But count Finder, well, down for the count.

Snow Leopard connects just fine to the share, Windows (XP, 2003, 7) clients work just fine as well.

Jason, Have you submitted a bug report on this issue with Apple? How about with the company who made your CIFS server? If not, I recommend you do so. The problem you describe is different than what I experienced in my environment. I couldn't even get Lion to do any remote disk mounts via the terminal. When we put our ISS into passive mode, all the disk mounts we try with Lion work fine via the Finder. Perhaps your CIFS device has it's own security mechanism built-in that needs adjustment to accommodate Lion.

Stanley,

I don't yet have a direct ticket open with Apple - I'll probably do this Monday. I do however have a ticket in with NexentaStor, and they have a ticket open with Apple Engineering regarding this. They are still awaiting a response.

The strange thing about this issue is that Lion seems to hit a wall interfacing with anything that uses a kernel level CIFS implementation. FreeNAS and others that use Samba seem to not be affected.

This is not our issue. This is a problem explicitly with the Finder, not smb or cifs, because while I'm getting the error that I cannot connect, if I go in terminal and navigate to /Volumes/[mounted share name] I have complete access, I can open files, edit them, save them there, etc.

I've been told it is a Finder issue to do with the new Versions feature, and some of the stranger errors I've gotten would confirm that.

For example to 'cure' the problem, at least for as long as the share is mounted, you can put the mac to sleep, wake it up, and the erroneous file icon turns into a volume icon, and the top level is available for opening files, but folders are still locked.

Putting it to sleep again unlocks the folders. There may be trips to get info in there, too. I've documented it but those docs aren't available right now.

Versions-aware apps like Textedit and Preview have issues, and will tell you that you have to unlock the files to edit them, while Versions-unaware apps like Word have no problems at all.

There are differences in how these things work depending on if the computer is bound to the Active Directory domain or not.

It's NOT SMB or CIFS, or else the access through terminal would fail as well, it's absolutely a Finder bug.

Here are the steps to make a Nexenta share visible and usable in the Finder in 10.7 on a non-AD-bound system ( I can't find my notes right now on the process for AD-bound systems):

connect to smb:\\[file server]\[share name] (using cifs: does not change anything)

Desktop volume icon (if 'Connected Servers' is checked in Finder prefs) is folder with ➖ tag, no access at all.

Close finder window (do not dismount volume by dragging it to the trash)

Open new Finder window, by navigating to the share via the sidebar:

Volume icon changes to network volume icon

cannot navigate folder hierarchy, but I can open files at the share root.

Put Mac to sleep.

Wait for sleep light to pulse, indicating the system is asleep.

Wake it up.

The ➖ icons on the folders change to regular folders and I can navigate the file hierarchy.

(The following only applies to Versions aware applications like TextEdit or Preview, no such issues happen with non-Versions aware applications, such as Word or Excel.)

Open a file, it's locked

try to make changes a dialog pops up: "The file <filename> is locked because you have not made any changes to it recently. If you want to make changes to the document, click 'Unlock' To keep the file unchanged and work with a copy click Duplicate"

Click 'Unlock' the file is now marked 'Edited' in the title bar.

Closing the saved document says The Document <document name> is on a volume that does not support permanent version storage. You will not be able to access older versions of this document once you close it."

Bruce,

One thing I should add to your post. After being able to navigate the folder hierarchy in Finder, any file operations you attempt (read or write) fail, stating that you do not have permissions to do that.

It's a really weird bug, to be sure. As I said before, I have not run into this in my FreeNAS trials (they use Samba on top of FreeBSD). It would appear the systems most affected by this utilize kernel-mode CIFS. However, I don't believe the true problem lies with Finder, even though that's where the symptoms most readily appear. My terminal outputs (as well as others I've seen) show very different permissions on what the OSX host sees and what the system actually has. For instance...

admin@NexentaStor:/volumes/zpool1/share$ ls -lh

total 4.6G

----rwx--- 1 jason.keller staff 351M Sep 23 09:08 VMware-viclient-all-5.0.0-455964.exe

----rwx--- 1 jason.keller staff 688M Oct 7 07:25 sol-11-exp-201011-live-x86.iso

admin@NexentaStor:/volumes/zpool1/share$

Jasons-MacBook-Pro:share jasonkeller$ ls -lh

total 17950858

-rwx------@ 1 jasonkeller staff 350M Sep 23 11:08 VMware-viclient-all-5.0.0-455964.exe

-rwx------@ 1 jasonkeller staff 687M Oct 7 09:25 sol-11-exp-201011-live-x86.iso

Jasons-MacBook-Pro:share jasonkeller$

UID on Nexenta is 1001, GID is 10.

UID on Mac is 501, GID is 20.

Here's what you see if you attempt a file copy operation in Finder...

Another quick update...

The permissions difference is also exhibited on shares that work in Finder (a Windows Server 2003 share). So maybe that's throwing me off a bit and it is a Finder bug, I can't be absolutely sure. Again, the command line cp still works though (although that's no workaround).

Well, on our system:

These are the same permissions I'm seeing on our share's on the Nexenta SAN, but they're consistent across both 10.6 and 10.7 :

-rwx------ 1 johnson johnson 3093832 Sep 1 13:53 zip code error.PNG 10.6, no domain login

-rwx------+ 1 johnson PHARMACY\Domain Users 3093832 Sep 1 13:53 zip code error.PNG 10.7 domain login.

(the 10.7 no domain login looks like the 10.6 one)

Now ours is a Win2k8 server, not Win2k3 but I suspect it's not material here.

The process to access the share via domain logins is:

mount smb://[server name]/[share name]

Close desktop window

open new Finder window, click on the server in the side bar, double click on the share to open it up. The desktop icon will convert to the mounted volume icon, not the folder and the top level is browseable.

Select all, do Get info and it'll convert the whole shebang to browseable, with the odd issues that are present in Versions-aware apps as I stated above.

Here's ascreenshot of the problem in action. I"ve mounted the nexenta share, according to finder I have no access.

Without doing anythng, I navigate in Terminal to the mounted volume and open a file with Preview in a subfolder of the root.

To my mind this pretty conclusively removes SMB as an issue, because if the permissions were screwed up there, it would have the same effect in Terminal.

Well it's official. 10.7.2 is out (build 11C74 ) and it does not fix this bug :-(

Bruce,

It's obvious to me that Apple isn't going to fix this any time soon. Although it's going to take extra legwork on our parts, I think we can somewhat offset the impact of this.

I've just turned over to Nexenta Core Platform, and by using napp-it with it, I've been able to get SMB working as it was under NexentaStor, but also managed to get AFP working nicely with it on the same share (via netatalk + avahi). Napp-it made setting up AFP much, much easier than it was previously (although the GUI is not as good as NexentaStor).

You might be able to layer napp-it into NexentaStor as well (as they're both based off NCP, although if you have Enterprise, they may not support this config). I've tested it to **** and hilder, and AFP seems to work just fine with Lion (just make sure to tweak the base permissions in the Volumes file). Makes it show up like an Xsan shelf.

I've tested it on both virtual and less than stellar native hardware, and it seems to work fine for basic file sharing (although you may want to stay away from dedup depending on your hardware and dataset size). I'm about to give Solaris11/Nappit a go soon as well, but I'll bet I run into the same SMB issues with Solaris (but I'll skirt the issue with AFP).

Well, since we're paying for the ENterprise verison, including support, going to a non-supported config is not applicable to us.

I went the other way and took advantage of the fact that the underlying SMB mount is not actually broken, it's only the Finder. I wrote a very short script that accepts a path as input and uses the system command to open it.

use strict;

my $in = $ARGV[0];

system "open \"$in\"";

exit;

(I r a perl hack, every problem is a nail and my hammer is made of camel :-)

Then I used the marvelous utility Platypus to make a droplet (download here if you want it). Drag the 'folder with a minus' on it and it opens up. If the underlying permissions let you see things, you can see the files and folders in there. Files can be opened directly in the finder, folders can be dragged onto the applet.

Kludgy, but better than voiding our support agreement with Nexenta :-/

It's 100% the Finder. All alternate tools (Path Finder, Forklift etc) work fine. You still see the icon that suggests you have no permission (must be reported by the Finder) but you have access.