Previous 1 2 3 4 Next 106 Replies Latest reply: Dec 18, 2014 6:06 PM by jcv Go to original post
  • Mad9000 Level 1 Level 1 (0 points)

    Scratch that. As others have discovered before me, my solution only worked until the next restart.

  • keg001 Level 1 Level 1 (0 points)

    Same here too. Tried some workarounds, but they only work until next reboot :-(

    temparary solution: turn off firewall -> work

    Apple should solve this problem quickly, I hope

  • macadmin78 Level 1 Level 1 (50 points)

    The app firewall is not playing nice.

     

    /usr/libexec/ApplicationFirewall/socketfilterfw --listapps

     

    ALF: total number of apps = 6

     

     

    1 :  /System/Library/CoreServices/Finder.app

                ( Allow incoming connections )

     

     

    2 :  /Applications/iTunes.app

                ( Allow incoming connections )

     

     

    3 :  /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java

                ( Block incoming connections )

     

     

    4 :  /Applications/Utilities/Migration Assistant.app

                ( Allow incoming connections )

     

     

    5 :  /Applications/Safari.app

                ( Allow incoming connections )

     

     

    6 :  /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Ma cOS/screensharingd

                ( Allow incoming connections )

     

     

     

    So the firewall reports that connections are allowed. But...

     

     

    tail -f appfirewall.log

     

    Oct 25 09:35:02 [my_managed_client] socketfilterfw[103] <Info>: Deny screensharingd connecting from [mydesktopmac]:51387 to port 5900 proto=6

    Oct 25 09:35:11 --- last message repeated 12 times ---

    Oct 25 09:35:11 [my_managed_client] socketfilterfw[103] <Info>: Deny screensharingd connecting from [mydesktopmac]:51388 to port 5900 proto=6

    Oct 25 09:35:41 --- last message repeated 12 times ---

    Oct 25 09:35:41[my_managed_client] socketfilterfw[103] <Info>: Allow sshd-keygen-wrapper connecting from [mydesktopmac]:51397 to port 22 proto=6

    Oct 25 09:36:39 [my_managed_client] socketfilterfw[103] <Info>: Deny screensharingd connecting from [mydesktopmac]:51402 to port 5900 proto=6

    Oct 25 09:36:48 --- last message repeated 12 times ---

    Oct 25 09:36:48 [my_managed_client] socketfilterfw[103] <Info>: Deny screensharingd connecting from [mydesktopmac]:51404 to port 5900 proto=6

    Oct 25 09:37:18 --- last message repeated 12 times ---

     

    So the app firewall reports that it will allow connections, then denys them anyway.

  • Cortig Level 1 Level 1 (0 points)

    Did you upgrade the client using the ARD Upgrade client command or did you install the .pkg that was available on the Apple Website.

    With the first approach, my clients get 370A61, with the second, they get 370A71.

    With the first, screensharingd is disabled in the built-in firewall. It looks like there is a codesigning issue.

    Everything is fine with the second approach.

     

    Reinstalling the client through the Apple web site version corrected the issue on 95% of my machines (one still stubonrly refused to allow screen sharing).

     

              Corentin

  • macadmin78 Level 1 Level 1 (50 points)

    I did my upgrades in bulk using ARD send unix command softwareupdate -i -r

     

    Just checked on affected client: version 370A73

  • ElliottRo Level 1 Level 1 (0 points)

    Thanks. It worked like a dream. Your recipe was very clear.

    I was failing to screen share to Lion a from newly updated Mavericks machine. The Lion box (a 1,1 Mac Pro) has always been twitchy about sharing its screen. I have to use Remote Management in place of Screen Sharing in Sys Prefs > Sharing

  • Cortig Level 1 Level 1 (0 points)

    Yeah, I saw that software update now offers yet another version of the client.

    Can you run this:

    codesign -d -v --verify   /System/Library/CoreServices/RemoteManagement/screensharingd.bundle

    to check whether there might be a problem with the codesigning of the bundle, which could explain why the process is still not allowed to communicate through the firewall?

     

    It doesn't return any error for me on the computers that are fine for screen sharing, but it does on the 370A61 ones.

    It also does on the 1 machine I have with 370A71 that still doesn't play nice with the firewall:

     

    /System/Library/CoreServices/RemoteManagement/screensharingd.bundle: a sealed resource is missing or invalid

    In architecture: x86_64

    resource modified: /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Su pport/SSFileCopyReceiver.bundle/Contents/version.plist

    resource modified: /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Su pport/SSFileCopySender.bundle/Contents/version.plist

     

     

     

     

              Corentin

     

    Message was edited by: Cortig

  • macadmin78 Level 1 Level 1 (50 points)

    yep:

     

    /System/Library/CoreServices/RemoteManagement/screensharingd.bundle: a sealed resource is missing or invalid

    In architecture: x86_64

    resource modified: /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Su pport/SSFileCopyReceiver.bundle/Contents/version.plist

    resource modified: /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Su pport/SSFileCopySender.bundle/Contents/version.plist

     

    I'll see if I can locate a current version that works. I have a bug filed with Apple as well. Almost certainly will get dropped into the "duplicate" pile.

  • Jason Pelletier Level 1 Level 1 (5 points)

    There could be a lot of things at play here but we are seeing the same issue that we have with another recent application and it has something to do with the Firewall, actually. The ApplicationFirewall is not honoring the commands you send it. If you look, you can remove the item but it isn't actually being removed. You can, however, remove it through the GUI just fine and then add it back in from Terminal and when you do it this way the app defaults to allow incoming connections.

     

    If you try, you'll notice that --blockapp and --unblockapp no longer work either. I have submitted a bugreport a few weeks ago on the state of the firewall and the command-line. This isn't just an issue with Mavericks, we're seeing it in 10.8.5 also but haven't gone further back to see where it breaks exactly.

     

    To recap:

     

    /usr/libexec/ApplicationFirewall/socketfilterfw --remove /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Ma cOS/screensharingd

     

    Does not work.

     

    /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Ma cOS/screensharingd

     

    Does not work.

     

    Remove via the GUI and then run the following

     

    /usr/libexec/ApplicationFirewall/socketfilterfw --add /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Ma cOS/screensharingd

     

    Does work and defaults to "Allow Incoming Connections"

     

    If you want to block the app

     

    /usr/libexec/ApplicationFirewall/socketfilterfw --blockapp /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Ma cOS/screensharingd

     

    Does not work.

  • Jason Pelletier Level 1 Level 1 (5 points)

    I should restate a little.

     

    Although there might be a bug in the code signing of ARD, the agent or ScreenSharing, the ARD developers might be getting bitten by a bug from the ApplicationFirewall where the agent gets added to the FW in a manner that sets its state to blocked by default and when they try to unblock it the command-line response is that its been done when in reality it hasn't.

  • macadmin78 Level 1 Level 1 (50 points)

    That could be, but if it is, the bug is not cli only. I tested an affected machine and set the app firewall to allow the connections via the gui. Both CLI and GUI show that the connections should be allowed. But they are still being blocked.

     

    I'm seeing issues with the Remote Desktop app as well. The new version sometimes refuses to launch after being quit. dmesg tells me that it is being denied write/create on a file (by sandbox). I sometimes have the same problem with Mail. It really looks as if Apple's sandbox has some issues.

     

    I haven't yet discovered the correct incantation to allow for relaunch of affected apps. I have to logout or restart to get back to work.

  • Jason Pelletier Level 1 Level 1 (5 points)

    You're right. I missed that one. So what we'll have to do for now, that appears to be working, is send a command to disable the firewall, screenshare or do whatever we need to do, get out and send another command to turn the firewall back on until all is fixed.

     

    I haven't seen an app issue yet so here's to hoping....!

  • skogarfoss Level 1 Level 1 (0 points)

    Same Problems - found solutions

    I found some solutions and hope it helps for others. See workaround from skogarfoss

    http://forums.macrumors.com/showthread.php?t=1659114

  • DG4444 Level 1 Level 1 (5 points)

    My screen sharing does not work with the firewall turned on.

     

    Turning the firewall off allows it to work.

     

    Turning it back on stops it from working.

     

    Tried to repair permissions and recived this warning

     

    "Warning: SUID file “System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAg ent” has been modified and will not be repaired."

     


  • Olaf Barthel Level 1 Level 1 (0 points)

    I found something odd in my Security & privacy/Firewall options, on two different machines. In the options, "Screen sharing" is set to "Allow incoming connections", and "screensharingd" is set to "Block incoming connections".

     

    I never added the entry for "screensharingd", and certainly never set it to "Block incoming connections". But the entry shows up both on my Mac Mini and my Macbook Pro. These settings are locked and changeable only by a user with admin rights. I am the only user who could change them, and I do not remember changing them. Why change them in the first place?

     

    Digging a little further, it appears that "screensharingd" is part of the RemoteManagement service, specifically the "screensharingd.bundle" in the "/System/Library/CoreServices/RemoteManagement" folder.

     

    Here's the fun thing: changing "screensharingd" to "Allow incoming connections" instantly made screen sharing work again on both machines.

Previous 1 2 3 4 Next