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

Hi again all,

So I've been running the Mac mini with a fresh install over the last few days and apart from the entries in the logs mentioned earlier everything seems peachy. I've had no issues with opening or saving or file locks from the Windows clients running MS Office. Saving modified files from other Windows programs (like Bluebeam) also seems to be sorted. (I'd been getting some nasty I/O errors on the clients.) I've yet to really give the file sharing a serious work out (using something like Revit) but it's looking very positive.

Of course, all this is far from conclusive but it's looking very much as if you do a vanilla upgrade to Mavericks (via the App Store) rather than a clean install of Mavericks, something in the previous OS's SMB configuration gets dragged into Mavericks. It's not the greatest of fixes but as much as creating install media etc. is a pain, it may save some headaches along the way.

Cheers,

Alex.

Pretty much the same problem.

- Mac Mini Server recently updated from 10.8 with server 2.x to 10.9 with server 3.
update was a mess (open directory was unusable), did a fresh install, user newly created, everything new …

- about a dozen mac clients equaly updated to 10.9 – troublefree

- the accounting-pc with win 8.1 –

one sucess is that the pc now can connect to the server via smb, which was a troublesome under 10.8 before the update.

But now my server logs are flooded with

smbd[60306]: File system does not support 0X40000, file attrs

smbd[60306]: File system does not support 0X0 time attrs

smbd[60306]: File system does not support 0X0, size attrs

for each file simply viewed in windows explorer

the climax was a non-responsive server, shutting off some minutes later. (after running about 7 days continously)

again, no sign of heavy usage in activity monitor.

here are the last lines of the log before crash:

Nov 13 18:03:04 hallea collabpp[36890]: objc[36890]: Class CSArchive is implemented in both /Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/C SService.framework/Versions/A/CSService and /Applications/Server.app/Contents/ServerRoot/usr/sbin/collabpp. One of the two will be used. Which one is undefined.

Nov 13 18:03:04 SERVERNAME collabpp[36890]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd. : LSXPCClient.cp #426 ___ZN26LSClientToServerConnection21setupServerConnectionEiPK14__CFDictionary_bl ock_invoke() q=com.apple.main-thread

Nov 13 18:03:04 SERVERNAME collabpp[36890]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd.

Nov 13 18:03:04 hallea kernel[0]: Sandbox: collabpp(36890) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:03:04 --- last message repeated 12 times ---

Nov 13 18:03:04 SERVERNAME sandboxd[169] ([36890]): collabpp(36890) deny file-read-data /Library/Preferences/.GlobalPreferences.plist

Nov 13 18:03:04 hallea kernel[0]: Sandbox: collabpp(36890) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:03:04 SERVERNAME sandboxd[169] ([36890]): collabpp(36890) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:03:34 --- last message repeated 6 times ---

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X40000, file attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0 time attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0, size attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X40000, file attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0 time attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0, size attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X40000, file attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0 time attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0, size attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X40000, file attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0 time attrs

Nov 13 18:03:45 SERVERNAME smbd[70483]: File system does not support 0X0, size attrs

Nov 13 18:08:04 hallea collabpp[37201]: objc[37201]: Class CSArchive is implemented in both /Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/C SService.framework/Versions/A/CSService and /Applications/Server.app/Contents/ServerRoot/usr/sbin/collabpp. One of the two will be used. Which one is undefined.

Nov 13 18:08:04 SERVERNAME collabpp[37201]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd. : LSXPCClient.cp #426 ___ZN26LSClientToServerConnection21setupServerConnectionEiPK14__CFDictionary_bl ock_invoke() q=com.apple.main-thread

Nov 13 18:08:04 SERVERNAME collabpp[37201]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd.

Nov 13 18:08:04 hallea kernel[0]: Sandbox: collabpp(37201) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:08:04 --- last message repeated 13 times ---

Nov 13 18:08:04 SERVERNAME sandboxd[169] ([37201]): collabpp(37201) deny file-read-data /Library/Preferences/.GlobalPreferences.plist

Nov 13 18:08:04 SERVERNAME sandboxd[169] ([37201]): collabpp(37201) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:08:35 --- last message repeated 6 times ---

Nov 13 18:08:41 SERVERNAME collabd[297]: [CSUserSessionServiceBase.m:48 466e000 +0ms] Detected Magic Superuser Auth Token

Nov 13 18:08:41 SERVERNAME collabd[297]: [CSUserSessionServiceBase.m:48 466e000 +0ms] Detected Magic Superuser Auth Token

Nov 13 18:11:37 hallea xpcproxy[37396]: assertion failed: 13A603: xpcproxy + 3438 [EE7817B0-1FA1-3603-B88A-BD5E595DA86F]: 0x2

Nov 13 18:11:37 SERVERNAME sandboxd[169] ([151]): xcscredd(151) deny file-read-metadata /Users

Nov 13 18:11:37 --- last message repeated 1 time ---

Nov 13 18:11:37 hallea kernel[0]: Sandbox: xcscredd(151) deny file-read-metadata /Users

Nov 13 18:11:37 --- last message repeated 41 times ---

Nov 13 18:11:37 SERVERNAME sandboxd[169] ([151]): xcscredd(151) deny file-read-metadata /Users

Nov 13 18:11:38 --- last message repeated 5 times ---

Nov 13 18:11:38 hallea kernel[0]: Sandbox: xcscredd(151) deny file-read-metadata /Users

Nov 13 18:12:08 --- last message repeated 24 times ---

Nov 13 18:13:05 hallea collabpp[37509]: objc[37509]: Class CSArchive is implemented in both /Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/C SService.framework/Versions/A/CSService and /Applications/Server.app/Contents/ServerRoot/usr/sbin/collabpp. One of the two will be used. Which one is undefined.

Nov 13 18:13:05 SERVERNAME collabpp[37509]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd. : LSXPCClient.cp #426 ___ZN26LSClientToServerConnection21setupServerConnectionEiPK14__CFDictionary_bl ock_invoke() q=com.apple.main-thread

Nov 13 18:13:05 SERVERNAME collabpp[37509]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd.

Nov 13 18:13:05 hallea kernel[0]: Sandbox: collabpp(37509) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:13:05 --- last message repeated 12 times ---

Nov 13 18:13:05 SERVERNAME sandboxd[169] ([37509]): collabpp(37509) deny file-read-data /Library/Preferences/.GlobalPreferences.plist

Nov 13 18:13:05 hallea kernel[0]: Sandbox: collabpp(37509) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:13:05 SERVERNAME sandboxd[169] ([37509]): collabpp(37509) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:13:35 --- last message repeated 6 times ---

Nov 13 18:17:33 SERVERNAME kdc[100]: Got a canonicalize request for a LKDC realm from local-ipc

Nov 13 18:17:33 SERVERNAME kdc[100]: LKDC referral to the real LKDC realm name

Nov 13 18:17:33 SERVERNAME kdc[100]: AS-REQ ardadmin@LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC from local-ipc for krbtgt/LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC@LKDC:SHA1.643FFE5AD30 1A5E36233B8E37A5C5B0F1314E5EC

Nov 13 18:17:33 --- last message repeated 1 time ---

Nov 13 18:17:33 SERVERNAME kdc[100]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ

Nov 13 18:17:33 SERVERNAME kdc[100]: AS-REQ ardadmin@LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC from local-ipc for krbtgt/LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC@LKDC:SHA1.643FFE5AD30 1A5E36233B8E37A5C5B0F1314E5EC

Nov 13 18:17:33 --- last message repeated 1 time ---

Nov 13 18:17:33 SERVERNAME kdc[100]: Client sent patypes: ENC-TS

Nov 13 18:17:33 SERVERNAME kdc[100]: Too large time skew, client time 2013-11-13T18:10:42 is out by 411 > 300 seconds -- ardadmin@LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC

Nov 13 18:17:33 SERVERNAME kdc[100]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ

Nov 13 18:17:33 SERVERNAME kdc[100]: AS-REQ ardadmin@LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC from local-ipc for krbtgt/LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC@LKDC:SHA1.643FFE5AD30 1A5E36233B8E37A5C5B0F1314E5EC

Nov 13 18:17:33 --- last message repeated 1 time ---

Nov 13 18:17:33 SERVERNAME kdc[100]: Client sent patypes: ENC-TS

Nov 13 18:17:33 SERVERNAME kdc[100]: Too large time skew, client time 2013-11-13T18:10:42 is out by 411 > 300 seconds -- ardadmin@LKDC:SHA1.643FFE5AD301A5E36233B8E37A5C5B0F1314E5EC

Nov 13 18:17:33 SERVERNAME kdc[100]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ

Nov 13 18:17:34 SERVERNAME AppleFileServer[2390]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument

Nov 13 18:17:44 --- last message repeated 1 time ---

Nov 13 18:17:44 SERVERNAME AppleFileServer[2390]: Logged out 0x7fc742879200

Nov 13 18:18:05 hallea collabpp[37808]: objc[37808]: Class CSArchive is implemented in both /Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/C SService.framework/Versions/A/CSService and /Applications/Server.app/Contents/ServerRoot/usr/sbin/collabpp. One of the two will be used. Which one is undefined.

Nov 13 18:18:05 SERVERNAME collabpp[37808]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd. : LSXPCClient.cp #426 ___ZN26LSClientToServerConnection21setupServerConnectionEiPK14__CFDictionary_bl ock_invoke() q=com.apple.main-thread

Nov 13 18:18:05 SERVERNAME collabpp[37808]: Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd.

Nov 13 18:18:05 hallea kernel[0]: Sandbox: collabpp(37808) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:18:05 --- last message repeated 13 times ---

Nov 13 18:18:05 SERVERNAME sandboxd[169] ([37808]): collabpp(37808) deny file-read-data /Library/Preferences/.GlobalPreferences.plist

Nov 13 18:18:05 SERVERNAME sandboxd[169] ([37808]): collabpp(37808) deny mach-lookup com.apple.coreservices.launchservicesd

Nov 13 18:21:04 localhost bootlog[0]: BOOT_TIME 1384363264 0

needless to say I'm having same problems ( mac mini (10.8->10.9),iMac(10.9), MBP plus some Win7 clients).

SMB2 is very fast but smbd makes trouble.

Once or twice a day the server load goes upto 20-30% regardless of the "real" load. The activity monitor shows a CPU load for smbd upto 106%. When I stop the smbd, it automatically restarts and everything is fine for some hours.

Addtional OD doesn't work.

Same problems, same configuration. Running 10.9, Server 3.01, file sharing is intermittent for Windows clients. It can run for hours and then a user is locked out of a file they have just modified. On the client side, the system machine will report "File Locked by User: <name>", and often that is the name of the client who created or was accessing the file. Meanwhile, the server log file is filling with these smbd errors: "File system does not support ... attrs", as outlined by others.

Server is running SMB sharing only. AFP is not enabled. No errors observed from Mac OSX 10.9 clients accessing the same shares.

This is a serious problem that Apple should address with urgency. It cuts to the heart of OSX Server as product. File Sharing is a key system function and even non-Server OSX clients have a need to share files.

Hi There,

same problems here.. i do not need to go into details but...

MacMini 10.9, Server 3.01 and 12 clients Windows and macs 10.9 most of them..

Please ... fix as soon as possible..

[replying to, or continuing my own post]...

This is a vexing problem. And a real nuisance.

I should add some details:

1. Our servers are running against a Windows 2000 Active Directory domain. The signon-functions work fine. Propagation of the user group memberships seem to occur fine.

2. Somehow, these group memberships interact with the ACL mechanism. Changing file protections in relation to these group memberships can decrease the number of "incidents". Maybe that is a clue.

3. It seems like most of the reports of problems from users involve MS Office applications. But then, this is what Windows users do all the time. Of dozens of incidents, I have one involving Acrobat. In the MSO instances, the user opens and is able to edit an existing file, and when attempting to close or save it (explicitely, not background), the application reports that the file is locked or in use. When in use, it is always in use by the same user who is experiencing the problem. Usually, the user can do "Save As" of their work to another location (usually a local disk). On the server, they are left with a ~temporary file created by the MSO application and the original file -- not inaccessible. The ACEs for this file are unchanged.

4. After these errors occur, the performance of the server degrades, or it even stops responding. Reboot resolves this (this suggests that whatever is happening is tieing up resources). The affected file is recoverable from the "admin" local account on the server. It does not contain the user's final modifications.

5. This server is running SMB only on these shares. AFP is disabled, server wide. We have confirmed that connections from the Windows clients are using SMB 2.1. Other SMB 1 connections are also in use (to Linux hosts running Samba). These connections are high-volume backup shares that get heavy use (Retrospect). They run flawlessly. However, all file protection on these connections have been disabled.

6. As mentioned at the top, there is something going on with the ACL mechanism. Simply changing the user group membership to a new one and then adding that new one to all the folders and files on the server should not change the rate of incidence, but it does seem to. However, it doesn't eliminate the problem.

If I were to guess, we have an interaction with some routine MSO file operation from Windows that is exercising a bug in the server file support for SMB in such a way that the server doesn't fully recover. The "xattr" errors in the log are roughly coincident, but given the subsequent slow-down of the server, the error could be anything.

The observations about the ACL interaction are tantelizing. We've spent a few hours analyzing our file protections. Still inexplicable.

just some quick remarks to your findings:

1. We have the problems also without Windows Domain.

2. interesting, never looked at it.

3. Cannot confirm that. My guess are somehow big files.

4. Reboot ist not necessary. The CPU-load of "smbd" climbs upto 100%. Just go to the activity monitor an kill "smbd". It will re-start automatically and work for some hours. Fot the time-being I need to do this once or twice a day.

Possibly we have somebody here to write a cron-job to check the smbd/cpu-load every hour and in case it's above 50% kill the process. Maybe a work around until Apple fixes this bug.

5.

6. ... plus something with LDAP from OpenDirectory.

let's hope for a quick solution and update from APPLE

Hello

Same Problem.

Mac OS X 10.9 Server (Upgarded from 10.8)

Server 3.0.1

In another forum, I've heard that you should "enable guest access" to each share (without Read access).

I have tried this now......

We will se.....

Regards

Florian

Hello!

Mac mini, 16GB RAM, Promise Thunderbolt RAID, Mountian Lion Server 2.2.2

SMB file sharing looks good, but an app running from this share intermitendly crashes, event log from Windows 7 tells me somthing about lost network share. (This was an upgrade from Server 10.6.8 running trouble free)

This is REALLY A BIG PROBLEM

@APPLE: You have nice toys like iPhone, iPad,etc., but how about a warning - "DON'T USE OUR SERVER SOFTWARE!" - it is just for playing not for serious working enviroment.

We are going to loose this customer and this customer will never come back to Mac 😠

Bye,

Christoph

Hi Christoph,

the probleme is even bigger.

As soon as the smbd goes to 100% and the network slows down, the CPU termperatur climbs up. My Mac Mini goes to 90°C CPU and 58°C inside the box.

Hey Alex, I have a "boatload" of lines in response to that command line, what does that mean?

Hi Florian,

did "enable guest access" helped you out?

Klaus Löfflad

http://train4media.de

Hi

Yes and No.....

Before I enabled the guest access, I had crashes about four times a day. After I changed this, it´s about one crash at 1 - 2 days. Additional I set the server to an auto reboot every night.

This is a workaround that works for me at this time.

Regards

Florian

no need to reboot the server. Just kill the "smbd", it will automatically restart.

Regards

Henry