Screen sharing useless now

I'm running two Macs, both running Lion. Screen sharing via back to my mac had been working great and was very responsive a few weeks ago. One side of my connection is on a very fast broadband line at my work while the other connection is at my home via Verizon fios (15 down, 5 up). While there was some lag with this set up, screen sharing is now completely broken. I can connect to the computers, but in most cases the whole thing just freezes and never comes back. If it does come back, I lose control of the mouse pointer in about 5 to 10 seconds and then I can't get control back.
I have changed nothing with my network connections. Can anyone suggest where I should trouble shoot this issue, or if other VNC clients could work better and not have similar problems?

Same issue being discussed here: https://discussions.apple.com/thread/4151334
I find I have to connect a keyboard and turn on the TV the Mac Mini is connected to before it comes right.
Also contemplating downgrading the Mac Mini to Lion as it's a giant pain in the a**!

Similar Messages

  • Closed connection in stalled screen sharing and now does not work

    Using screen sharing I created a second admin account on the computer 2. I enabled quick account switching and tried to switch user accounts to the new admin account. I linked the new admin account to be shared with my existing admin account on computer 1. The screen never switched over to my new admin account and I couldn't quit screen sharing so I closed the connection with computer 2. Now I can't share the screen with computer 2 at all, even using my original admin account (not the newly created one). I can't reboot my computers because it will abort jobs that need to remain running.
    I can still share screens between computer 1 and other computers (i.e. not computer 2) but when I try to share with computer 2, it doesn't even ask me to log in.

    This issue remains unresolved, but since Apple Discussions decided to archive my question it is impossible to receive any replies.
    GRR.

  • Having security issue with SL Screen Sharing

    Hello,
    Maybe I am missing some new setting in Snow Leopard that increases screen sharing security, but as it is, screen sharing is now insecure on my network.
    Prior to Snow Leopard I would log into my Mac from another without selecting the "remember this password in my keychain"... after finishing the session, I would again be asked for my password before ropening a new screen sharing session. All machines on the network were Leopard.
    Now, with all macs on the network Snow leopard, on one of the machines I can log on in the morning, work for a while, quit screen sharing, and go back in an hour and start sharing that mac's screen with no password required. Anoyone else can can do this also! I have checked the keychain on the Mac I am viewing from and there does not seem to be an entry there for screen sharing.
    On another of the Snow machines it always asks for the password, but on 2 of them, once I have started viewing another Mac's screen a password is no longer required regardless of the fact that I haven't checked that "remember password" .
    This means that after I leave a Mac from screen sharing it, someone else has full access to that machine just by clicking on the Share Screen button... unless I can close the hole somehow.
    Any ideas or a way to fix this would be appreciated.
    Thanks
    Jamy

    Hi all,
    I just upgraded to Snow 10.6.2 so through 2 separate updates, this security hole on all 3 Macs on my network exists.
    To test it I went to an office and opened a screen on another (Snow Leopard) Mac that was set up to allow users only to connect. I then quit Screen sharing, and returned 3 hours later, only to be able to open the Hard Disk window and return to that Mac's screen without any passwords required. I was very careful not to allow the Keychain to remember me.
    Since I originally posted I see another thread has begun up expressing essentially the same issue.
    I would strongly advise anyone who uses Snow Leopard in a secure environment , at least through 10.6.2, to disable screen sharing or risk unauthorized access, or monitoring, of their Macs from within their networks. Screen Sharing's security settings (if they work at all) do not work on Snow Leopard the same as they worked on Leopard.
    I have not found a fix for this in the 3 weeks since I first noticed it other than to disable it, or restart the Mac I started the session from, then it will ask for a password, but that is hardly an acceptable fix in some secure or corporate environments (akin to having to restart in order to empty the browser cache when accessing webMail lol)
    Regards,
    Jamy

  • If Your Screen Sharing Stops Working, Read This

    SCENARIO: I have a network of Macs. On my main machine (a Mac Pro), I have set up bookmarks in Safari that link to the Screen Sharing URLs for other Macs on my network (Mac minis, MacBook Air). For example:
    vnc://192.168.1.51
    vnc://192.168.1.52
    So I can kick off a Screen Sharing session with one of those Macs simply by clicking the appropriate bookmark in Safari.
    PROBLEM: Sometimes when I do this, one of two things happens... either the Screen Sharing program launches in the dock but the window for the other Mac does not appear at all, or the Screen Sharing program launches and a small black window (with nothing visible inside) appears. Killing and restarting Screen Sharing does not help, and restarting the remote Mac does not help.
    SOLUTION: One way to solve this problem is to restart the Mac where you are attempting to use Screen Sharing. But this is overkill; it works because it incorporates the second, easier solution to the problem:
    1. Launch the Activity Monitor program.
    2. In the Process Name list, look for "NetAuthAgent". It may show as "Not Responding".
    3. Select NetAuthAgent, and then click Quit Process (the red stop sign button at the top of the Activity Monitor window). Then, click Force Quit.
    Your Screen Sharing should now work.
    It appears that as part of connecting to the remote Mac, your Mac must authenticate itself... and NetAuthAgent is part of this process. If this program freezes, hangs, or locks for any reason, the authentication will not work, and you cannot use Screen Sharing. Killing NetAuthAgent is harmless, as far as I can tell, and it will automatically relaunch the next time it is needed.
    For anyone else having problems with Screen Sharing not working correctly, I hope this information helps.

    having related problem with NetAuthAgent
    "loginwindow" process in activity monitor is Not Responding constantly (through warm and cold reboots)
    this causes a number of problems, slow network performance, hangs, no ability to restart/shutdown
    killing "NetAuthAgent" is the only way to make "loginwindow" process responsive again
    and restores lost functionalities
    having this problem across three networked machines (macpro, macbook pro, mac mini) all running 10.5.2
    have reapplied the 10.5.2 combo upgrade but no fix. only witnessed this problem since 10.5.2

  • Screen Sharing: reducing network overhead?

    After setting up screen sharing, are there some ways of keeping the overhead low in terms of CPU and hard drive load?
    I noticed after getting screen sharing going, a fair amount of hard drive chatter on the computer who's screen was being shared; not sure about the computer using that screen...
    I'll be operating a desktop mac via screen sharing from a mac book pro...doing a little 3D rendering and file management...maybe batch processing.
    thanks for any info on this!
    ray

    QT is still on 1.5Mps, which I had set before trying the tips suggested here. iChat video still has the 500Kbps setting I gave it as advised.
    Oddly, screen sharing is now available even though I am back on wireless not ethernet. This all seems a bit unpredictable and unreliable for something which is supposed to be 'easy' screen sharing!
    Thanks again for the help people have given which has (hopefully) fixed this.

  • Screen Sharing trying to connect to Apple Kerberos server?

    I'm using a MacBook Pro running 10.10.1. When I connect to other Macs via Screen Sharing, it now takes a very long time to connect (a lot longer than when I was on 10.9).
    The culprit seems to be this:
    1/7/15 11:00:08.606 AM NetAuthSysAgent[10688]: NAHSelectionAcquireCredential The operation couldn’t be completed. (com.apple.NetworkAuthenticationHelper error -1765328228 - acquire_kerberos failed username@WELLKNOWN:COM.APPLE.LKDC: -1765328228 - unable to reach any KDC in realm WELLKNOWN:COM.APPLE.LKDC, tried 1 KDC)
    So it's trying to look me up on Apple's Kerberos server, and timing out. Any way to stop Yosemite from doing this? Or is there another solution?

    Make a rule in Little Snitch to forever deny outgoing connections for NetAuthSysAgent to port 88 (kerberos).
    No more delays.

  • Screen sharing in Mountain Lion iMessage

    Screen sharing doesn't seem to work in Mourntain Lion. Anyone know if there is a fix? Screen Sharing is enabled, but when trying to choose share screen it is all greyed out.

    Hi,
    It will work if the Messages App has either AIM (or AIM Valid) names or Jabber valid IDs listed as accounts.
    (i.e the iChat side of things)
    I have Screen Shared to  Snow Leopard and Leopard computers.
    My G4 tower will boot into an iChat 3 version.
    This will only accept Video Chats if the iChat 3 end calls  ( I have yet to try Screen Sharing with iChat 3).
    I actually don't have a computer that I can booth into Lion whilst being in Mountain Lion.
    Lets say you are using an iCloud issued @me.com name as the iMessages Apple ID
    Go to the Message Preferences > Accounts and us e the + button
    Click the AIM Choice.
    Add the @Me.com name in full
    Click Done.
    You will now have an AIM Account in the Accounts list
    In the window Menu it will now says Buddies (CMD + 1)
    This will  show you the Buddy List
    Add AIM or AIM Valid Buddy names.
    In the Video Menu Screen Sharing will now be an option you can tick (or Untick)
    You could also Add GoogleTalk or other Jabber IDs to the Accounts list.  (GoogleTalk is a Jabber server)
    Screen Sharing is AIM to AIM or Jabber to Jabber.
    10:26 PM      Thursday; October 4, 2012
    Please, if posting Logs, do not post any Log info after the line "Binary Images for iChat"
      iMac 2.5Ghz 5i 2011 (Mountain Lion 10.8.2)
     G4/1GhzDual MDD (Leopard 10.5.8)
     MacBookPro 2Gb (Snow Leopard 10.6.8)
     Mac OS X (10.6.8),
     Couple of iPhones and an iPad
    "Limit the Logs to the Bits above Binary Images."  No, Seriously

  • Screen Sharing my iMac Running Snow Leopard

    So I've enabled Remote Management on the iMac running Snow Leopard. I prefer this tab to the screen sharing tab because I like to have the remote management status tab active on the top menu bar.
    A screen sharing session now disables the screen saver and display sleep on the iMac. Is there any way to reenable screen saver and display sleep when a screen sharing session is active?
    My next question is: what is the minimum configuration in the remote management tab required for screen sharing?
    Thanks,
    Ivan

    This post seems to be a duplication
    10:47 PM      Tuesday; December 27, 2011
    Please, if posting Logs, do not post any Log info after the line "Binary Images for iChat"
      iMac 2.5Ghz 5i 2011 (Lion 10.7.2)
     G4/1GhzDual MDD (Leopard 10.5.8)
     MacBookPro 2Gb (Snow Leopard 10.6.8)
     Mac OS X (10.6.8),
    "Limit the Logs to the Bits above Binary Images."  No, Seriously

  • Ichat screen sharing - "slow network"

    Hi
    I am trying to use screen sharing between an intel imac and a mac book pro over the internet. Both running latest versions of Leopard. The enable screen sharing menu item is greyed out. Connection doctor has a red cross next to "share my screen" with the message "(slow network)". Same for host multiperson video. Share remote screen has a green tick.
    I have enable upnp on my router as recommended elsewhere. No change. Similarly, I have also set Quick Time streaming speed to 1.5 Mbps. No change.
    I have tested by internet speeds at www.auditmypc.com:
    download: 9782Kbps
    upload: 526.4 Kbps
    Is the upload speed causing the problem? Any tips on how to fix this pls (Virgin Media cable broadband)?
    Thanks

    QT is still on 1.5Mps, which I had set before trying the tips suggested here. iChat video still has the 500Kbps setting I gave it as advised.
    Oddly, screen sharing is now available even though I am back on wireless not ethernet. This all seems a bit unpredictable and unreliable for something which is supposed to be 'easy' screen sharing!
    Thanks again for the help people have given which has (hopefully) fixed this.

  • Screen Sharing Broken for Network Account Admins Mac OS X Server

    Re: OS X 10.8.4, Server.app 2.2.1
    After replacing a failed Airport Extreme -- and the resulting changes in server IP address -- Screen sharing is now broken for "Network" account administrators. "Local" adminstrators can screen share successfully.
    When logging in as a Local Admin, the System Log contains a single entry:
    Authentication: SUCCEEDED :: User Name: localadmin :: Viewer Address: 10.0.1.6 :: Type: DH
    When logging as a Network Admin, a similar line appears:
    Authentication: SUCCEEDED :: User Name: testnetwork :: Viewer Address: 10.0.1.6 :: Type: DH
    followed by screen-fulls of other log messages, eventually ending -- a minute or two later -- with:
    screensharingd[77693]: uid 1034 not found
    screensharingd[77693]: unable to get width and height of display.
    at which point the client sees a "Error: Network connection lost." alert. 1034 is the UID of "testnetwork", as seen in
    dscl /LDAPv3/127.0.0.1 -list /Users UniqueID
    So apparently, Network users are authenticated, but screensharingd cannot find the user.
    changeip -checkhostname returns "success". Just to be sure, I  "Updated the Host Name" as suggested by the "Network Configuration Has Changed" alert in Server.app -- problem remains.
    How does one debug this? Are there more comprehensive debug logging options available for screensharingd or login window? Anyone else seen this problem?

    Linc: thanks for your inquiry.
    Here are more steps I've taken to solve this problem:
    1) From a Time Machine backup to a test partition, I restored the server from before the failure of the base station and found that the login problems were present then.
    2) On yet another test partition, I created from scratch a new OS X Server. Added a local administrator, and a network admistrator and discovered the same problem: network administrators cannot screen share, although in this case, they are simply unauthorized.
    Using dscl, things look OK: there is a /Local/Default/Groups/com.apple.access_screensharing that lists only the admin group, and the admin group contains networkAdmin.
    Furthermore, I can log in as the networkadmin from the login window, as "Other".
    Furthermore, I can ssh into the server using the networkadmin credential.
    I used odutil to boost the logging OpenDirectory log level. The logs are very verbose, but to my eyes, it looks like OD recognizes the networkUser, but screensharingd fails to authorize. See logs below.
    Can someone confirm that screen sharing from network admin accounts works at all? Is there a way to elevate screensharingd logging to find out more about why it rejects network admins?
    TIA
    /var/log/opendirectoryd.log
    4643.65273.65277, Module: search - ODQueryCreateWithNode request, NodeID: 3D4241C6-FAFF-4816-8F7C-B3E0ED6F56A6, RecordType(s): dsRecTypeStandard:Users, Attribute: dsAttrTypeStandard:RecordName, MatchType: EqualTo, Equality: CaseIgnore, Value(s): networkadmin, Requested Attributes: dsAttributesStandardAll, Max Results: 1
    4643.65273.65277, Node: /LDAPv3/127.0.0.1, Module: search - queuing request to connection - '/LDAPv3/127.0.0.1:ldap:406935A6-9ADB-413A-A82B-7F30F4E9E5A1'
    4643.65273.65277, Node: /LDAPv3/127.0.0.1, Module: ldap - adding 'dsAttrTypeStandard:RecordName' for ambiguous name query
    4643.65273.65277, Node: /LDAPv3/127.0.0.1, Module: ldap - adding 'dsAttrTypeStandard:RealName' for ambiguous name query
    4643.65273.65277, Node: /LDAPv3/127.0.0.1, Module: ldap - query with filter - '(&(&(objectClass=inetOrgPerson)(objectClass=posixAccount)(objectClass=shadowAc count)(objectClass=apple-user)(objectClass=extensibleObject))(|(uid=networkadmin )(cn=networkadmin)))', baseDN - 'cn=users, dc=testserver,dc=local'
    4643.65273.65277, Node: /LDAPv3/127.0.0.1, Module: ldap - found result - 'uid=networkadmin,cn=users,dc=testserver,dc=local'
    4643.65273.65277, Node: /LDAPv3/127.0.0.1, Module: ldap - ODQueryCreateWithNode completed, delivered 1 result
    4643.65273, Node: /Search, Module: search - ODQueryCreateWithNode completed, delivered 1 result
    4643.65278 - Client: screensharingd, UID: 0, EUID: 0, GID: 0, EGID: 0
    4643.65278 - ODNodeRelease request, NodeID: 184CFA31-1EB8-4384-B9CA-D04A93736CB1
    4643.65278, Node: /Search - ODNodeRelease completed
    clearing all node authentication connections
    /var/log/system.log:
    screensharingd[4665]: Authentication: FAILED :: User Name: networkadmin :: Viewer Address: 10.0.1.6 :: Type: DH

  • BT broadband drops iChat screen sharing when voice call initiated

    Just a question, and a warning if anyone out there in the UK is contemplating BT (British Telecom) broadband, you might get this issue.
    I can share a screen with someone on BT braodband, but using voice at the same time makes the video very slow and jumpy.  So, my solution used to be to phone on a normal phone line and just use the iChat for screen sharing. 
    Now, my mother has switched to BT broadband + BT phone (was Metronet broadband + BT phone), now, every time I start a voice call at the same time as screen sharing it crashes the iChat app.
    BT tell me it is porbably a fault with the applicaiton, and the fact that it worked for over 3 years whilst on Metronet is pure coincidence.  The whole reson she switched to them was to try to save a little money, they want to charge £50/hr to diagnose what the issue might be.
    Does anyone else have this problem?  If so, has anyone discovered the cause?
    Thanks
    Stephen

    HI,
    Describe in more detail please what you mean by "Crash"
    Can you Video Chat ?
    Can You Audio Only chat ?
    These both use the same ports when making a connection and during the actual Chat
    A Screen Share is  an Audio Chat+ and uses  a random port for the Screen Sharing side.
    As this port is random you cannot set up Port Forwarding or Port triggering (If the router part does that) and you need to use UPnP (Universal Plug and Play).
    UPnP is normally On by default in the later Home Hubs (2 and 3)
    Early versions
    If she happens to be using iChat 3 or earlier though there can be issues as the Hub is capable of VoIP and using the phone over the Internet.
    VoIP uses a protocol over the internet called SIP (Session Initiation Protocol)
    This has internationally agreed ports  of 5060-5063 (it uses one and will try one at time if not available)
    Early version of iChat  also used port 5060 to make connections.
    However some ISPs started to Block these ports and then charge extra for this "extra" service (sometimes without notification)
    Some Modems that can "route' the Phone over the internet also need to have setting changed to allow iChat to work,  (Basically the device has a SIP filter regardless of the addresses on the data packages meaning they don't get to the computer and get "lost" as they are not addressed to the Phone either).
    Later versions of iChat moved away from the 5060 port(s) and used 16402 as the first choice.
    Skype that also uses SIP to make connection have never used the 5060 range.
    If there is  a error message about Unexpectedly Quit we could do with seeing the "Crash Log" from her Home Folder/Library/Logs/CrashReporter/iChat.
    11:15 PM      Friday; April 6, 2012
    Please, if posting Logs, do not post any Log info after the line "Binary Images for iChat"
      iMac 2.5Ghz 5i 2011 (Lion 10.7.3)
     G4/1GhzDual MDD (Leopard 10.5.8)
     MacBookPro 2Gb (Snow Leopard 10.6.8)
     Mac OS X (10.6.8),
    "Limit the Logs to the Bits above Binary Images."  No, Seriously

  • I downloaded the beta of iMessage, replacing iChat.  Now screen sharing does not seem to be available (shaded out.)  Anyone have a suggestion?

    I downloaded the beta of iMessage, replacing iChat.  Now screen sharing does not seem to be available (shaded out.)  Anyone have a suggestion?

    Hi,
    I am presuming you are looking in the Video Menu but are finding you do not have "permission" to enable Screen Sharing.
    In Messages Menu > Preferences > Video section what speed setting is set in the Bandwidth Limit drop down ?
    It should be no lower that 200kbps if you want to Video chat or Screen Share  (the Min for both is 128kbps)
    Even if it shows a speeds higher than this change it to something like 500kbps then close/Quit Messages and then restart it. (i.e change the setting anyway to give a bot of a jolt)
    10:18 PM      Thursday; May 17, 2012
    Please, if posting Logs, do not post any Log info after the line "Binary Images for iChat"
      iMac 2.5Ghz 5i 2011 (Lion 10.7.4)
     G4/1GhzDual MDD (Leopard 10.5.8)
     MacBookPro 2Gb (Snow Leopard 10.6.8)
     Mac OS X (10.7.4),
    "Limit the Logs to the Bits above Binary Images."  No, Seriously

  • Screen Sharing and Hot Corners/expose bug?

    I tried searching but I came up with nothing. I have an iMac and a Macbook. On the iMac I have hot corners set up to use expose. On the bottom left I have it show the desktop and on the bottom right I have it show all windows. Now when I use my macbook to screenshare with my iMac and try to drag a file on the iMac, it activates one of the hot corners even though my mouse cursor is no where near either of the corners. If I deactivate the hot corners, I can drag just fine but I don't want to have to do that every time I use screen sharing. So this is making screen sharing pretty useless. Anyone else have this problem? I just submitted a bug report too.

    I have the same problem. Very annoying.

  • Screen sharing in 10.8 slower than in 10.7?

    Hi everyone,
    I use screen sharing a lot with my 10.7 server and 10.7 clients. I have now set up a fresh installation of 10.8 Server, but screen sharing to it seems way slower on the same connection. It takes around 10 seconds to connect (2-3 seconds with 10.7) and the speed (i.e. when dragging windows or typing) is slower, too.
    Did you encounter similar issues?
    Thanks
    Björn

    I have what I believe is the same issue. Used screen sharing to connect to my headless (no monitor) mac pro early 2008 running Lion from my early 2009 Mac Book Pro 17" also running Lion. I had them connection view internet sharing over an ethernet cable. There was no lag, I could eaisly use program and even watch video.
    After upgrading both to Mountain Lion now screen sharing is usless. Apps are slow, mouse movements do not track well and forget about video, it doesn't even render.
    I did notice something interesting, if i do connect a monitor to the headless mac pro the issues go away. Everything runs smooth like it used to headless on 10.7 until i disconnect the monitor, then back to slow town.
    Any ideas? I'm getting close to reinstalling 10.7 as 8 is useless to me at this point.

  • Screen Sharing/network problem seems confined to 1 volume. What's the fix?

    I am having a networking problem on one of the volumes of my multi-volumed, three-Mac local area network, and I need a networking guru to identify the specific software file(s), application(s), or system configuration that is the cause of the problem. I have already spent several hours checking and re-checking the various hardware and system preference settings involved, and I have narrowed the problem down to a software corruption issue and/or system configuration issue on one volume.
    I now need someone to identify specifically what the nature of the problem is, and how to eliminate it. I am not looking for a sledgehammer solution that says I should re-install all of the Mac OS X software on the problem volume. That may be held in reserve as a last resort. I'm looking for a more elegant approach, one that points out the specific corrupt files to remove without disturbing everything else.
    Here's some background to set the context. I have a MacBook Pro laptop; a PowerMac iMac G5; and a PowerMac G4 hooked up in a network. All are running Leopard 10.5.8. All have file sharing and screen sharing enabled. Besides being able to connect to each other using registered users, my goal here is for each of the Macs to be able to share the screen of the others upon my demand. Since each of the 3 Macs can theoretically share the screens of the other 2, that makes a total of six possible connections. Five succeed; one does not. That's the problem. I am trying to determine why the iMac G5 cannot share the screen of the MacBook Pro.
    The iMac G5 has no problem sharing the screen of the PowerMac G4. That connection is fast and immediate. But, every time that I hit the Share Screen button on the iMac G5 to try to connect to the MacBook Pro, I get a window with the blue barber pole spinning for two or three minutes as it is allegedly "Connecting to Mac Book Pro," followed by a window with a headline telling me that "Connection Failed to MacBook Pro." The text within that window goes on to say: "Please make sure that Screen Sharing (in the Sharing section of System Preferences) is enabled on the computer to which you are attempting to connect. Also make sure that your network connection is working properly."
    Well, as I indicated, the PowerMac G4 has no problem sharing the screen of the MacBook Pro, so the Screen Sharing settings on the laptop are correct; and the iMac G5 can share the screen of the PowerMac G4, so its network connection is working properly in that regard. It is only in regards to sharing the screen of the MacBook Pro that the iMac G5 is not working properly.
    The reason why I say that the issue must be unique to the one volume in question, let's call it "iMacG5 Music," is that another Leopard volume on the same computer has no problem whatsoever in sharing the screen of the MacBook Pro. Whenever I boot up in that volume, let's call it "iMacG5 JMB," it makes a network connection with a registered user name immediately, and it is able to share the screen of the MacBook Pro within a second of my issuing the command. In sharp contrast to the success of the iMacG5 JMB volume, the iMacG5 Music is unacceptably slow (several minutes slow!) in making a network connection with the MacBook Pro, and it always fails to share the screen of the MacBook Pro, preferring instead to take about three minutes to attempt the connection, before announcing its failure.
    Since the iMacG5 Music volume makes an immediate network connection to the PowerMac G4, as well as sharing the screen of the PowerMac G4 the moment I ask it to, I have concluded that the hardware of the iMac G5 is just fine. The problem seems confined to the system software and/or associated networking files that are unique to the iMacG5 Music volume. I just don't know what those files could be, or where the problem lies, so I've issued this call for help.
    Let me add one more little twist to this puzzle which baffles me even more. I use external LaCie Firewire drives as clone backups of my Macs. As part of my trouble-shooting process, I booted up from the cloned versions of the iMacG5 JMB volume and the iMacG5 Music volume. What I learned surprised me!
    The iMacG5 JMB clone worked just fine in making a fast network connection to the MacBook Pro, as well as sharing the screen of the MacBook Pro. I expected that. What I did not expect was that the iMacG5 Music clone was also able to make a fast network to the MacBook Pro, as well as share its screen!
    Yes, that's right. It's weird! Screen sharing works OK when I start-up from the clone of the iMacG5 Music volume, but it does not succeed when I boot up on the source itself! I was surprised to find that out, but I'm glad I did.
    (Over the past few days since I executed the last clone, I did use Drive Genius to de-frag the source volume, and maybe that has contributed to the problem I am now encountering. But it's hard to say, since nothing else seems to be amiss.)
    One solution, I suppose, would be to sync the clone back to the source. But, before I do that, I'm just wondering if anyone has a clue as to the nature of this problem on the source volume and what I might do to remedy it—short of re-installing the system software or restoring from the clone. Anyone have any insight to this problem?

    CORRECTION #2:
    Ignore the previous "CORRECTION" post.
    Oops, excuse me, I wrote that sentence correctly the first time.
    I was trying to point out that the ability of the iMac G5 computer to connect quickly and effectively to the PowerMac G4 when booted up into the iMacG5 Music volume was an indication (to me, anyway) that there is nothing wrong with the computer's hardware, nor its network connection ability, but that the problem lay somewhere in the files/settings used to connect to the MacBook Pro, which it cannot accomplish.
    This is what happens when I get engrossed in one of these technical morasses and it ***** me into its vortex all through the night... time for bed.

Maybe you are looking for