Q: Server File Sharing unstable on mac and windows network on Mavericks and OSX Server 3.0

Should IPv6 it be disabled?

Hello Alex,

I am not expert on this, I have however been in touch with someone at the Apple server group. I have provided them logs and dumps and data up the wazoo. They keep on asking me for more data.

The symptoms that I found was that whenever I try to connect from Windows 8/8.1 to OS X 10.9.1 server share, and try to open simple .txt files that I get an error like "Server does not support this action....". However when I disable SMB 2/3 on Win 8/8.1 and restart, then remap that network server share, then I can open these files no problem. There must be a problem with the Apple SMB 2 implementation that causes this error, and Apple needs to fix this.

So, it does help for me to disable SMB 2/3 on Windows 8/8.1, but it's not a solution. I do not know but I don't see the log entries like "File system does not support 0X40000, file attrs"..... But maybe I am just not looking in the right place. Nothing shows up in the Console and when I search for it "All Messages" selected nothing comes up.

I really hope that they will find a fix for this soon. Thanks.

Martin

IP V6 is enabled, Link-local only to reduce the traffic.  When it is set to automatic it starts dumping packets.

Hi all, have new Server release 3.0.2 solved file sharing problems?

Just ran my suite of tests, and I see no difference in the file sharing side of things.  SMB2 still fails the directory ennumeration test, and SMB1 still crashes under heavy load. 

To be fair the release notes for Server 3.02 did not list any changes for file sharing.

@JordanCK:

See the following, which may or may NOT apply to your setting:

https://discussions.apple.com/thread/5483424?tstart=0

I'm also having the same issue on 2 large mixed networks where MS office files are 'locked' by Unknown User for no reason.  Really tearing my hair out.

When working with Office files directly off of a fileshare, there will be locking issues. Macs & PCs handle file-locking differently.

One known step that helps, is to create a folder named:

.TemporaryItems

(with the dot) at the top of each sharepoint in question (where Office/Word/Excel/PPT files are stored), with full access permissions for Everyone. Far better than "Everyone" would be a group you create that includes all the allowable users in question.

One known step that helps, is to create a folder named:

.TemporaryItems

 

(with the dot) at the top of each sharepoint in question (where Office/Word/Excel/PPT files are stored), with full access permissions for Everyone. Far better than "Everyone" would be a group you create that includes all the allowable users in question.

Thanks for that - does this have to be created in every folder (there are thousands on the share) or just at the top level?

Waiting for that answer too. Sounds like something I really need to deploy

Hi, sorry for the delay. It's at the top level of every share.

Create an ACL for .TemporaryItems with the group being Staff (all users are a member of the Staff group by default), and give Staff full permission (see further below).

See http://support.apple.com/kb/ta23804
NB: The following, which should (most definitely) already be the case:

     "Use a shared directory service instead so that every user logs in with their own unique ID.

     Don't share a server user—each client user should have a unique ID."

You will have to use the Terminal to get this done, please go this route. Do not (not not) use a hack to show invisible files, in the Finder, I doubt that would cause the item to show up in Server.app and I didn't bother to even try.

Open a Terminal window, type in:

cd

(followed by a space)

and then you can drag your parent folder (that serves as a sharepoint in question) onto the Terminal window to fill in the path.
Then press enter. That will take you TO the location in question.

Then use:

sudo mkdir .TemporaryItems

(then, all on one line):

sudo chmod -R +a "group:staff allow readsecurity,readattr,readextattr,list,search,read,execute,writeattr,writeextat tr,delete,add_file,add_subdirectory,delete_child,write,append,file_inherit,direc tory_inherit" .TemporaryItems

You can copy-paste the above line. Otherwise please do note there is a space between the final quotation-mark and .TemporaryItems

Best regards,

-- David

Seed to 10.9.2 with possible SMB2 fix available on the dev center. I'll test it tonight

Tested, and I see no change in either SMB1 or SMB2.

Since we installled the 10.9.2. seed the SMB access stopped failing, we still get the attrib error on console, but that's all we can tell...

Similar first experience, but it is too early to tell.

First, we created the hidden .TemporaryItems folder at the root of each share with the "sticky" attribute.  This seemed to eliminate complaints from the users of MS Office on Windows.  But that is just a week, so wait and see.  Then installed 10.9.2 seed, and SMB hasn't misbehaved.  But the extended attribute errors are still in the log.  Are they harmless?  Still wondering.

This will take a week of experience before I'm ready to declare anything fixed.

Except (off topic):  Gmail support in OSX Mail is fixed (really) in the seed.  The difference is dramatic and very pleasing.