Share My Desktop: Can't Write to /tmp?

[Makosuke]

Haven't really dug into this yet, but I'm having a weird issue with the simple VNC server Share My Desktop (by Bombich, the Carbon Copy Cloner guy). The problem is that, when I start the server, it pops up an error saying it failed to write a password to /tmp. When I then try to log into the server I get a authentication error, so the password appears to be failing as a result of this.

This is strange for two reasons; one, /tmp seems to have permissions such that it can be written to by Share My Deskop, and two, it worked just fine not 48 hours earlier. The only differences between when it worked and now are that it's being run under a different user (though it was a non-admin user before, and an admin user when it DOESN'T work), I copied the app from its disk image to the Applications folder, and I ran repair permissions.

Anybody seen something like this happen before? Any guesses?

 

[cbiffle]

Any chance there's a pre-existing password file in /tmp that it won't (or can't) overwrite?

Files in /tmp are "sticky," so if e.g. another user has a leftover password file in /tmp, and if the program uses a fixed name (which is bad practice), you won't be able to overwrite the previous file.

This is, of course, purely hypothetical.

 

[Makosuke]

That's certainly a thought--I'll have to poke around in /tmp some more and see what's in there. I'd imagine Bombich doing a better job writing it than that, but people make mistakes. I suppose if it somehow left a version of its own password in there on the other user's account, it might not have permission to replace it--/tmp does map to the same private directory across users, right?

 

[paleck]

As I understand it if you have Apple's Remote Desktop Client running it is based loosely around a VNC server. Is it possible they are trying to use the same password file in /tmp?

 

[Makosuke]

As I understand it if you have Apple's Remote Desktop Client running it is based loosely around a VNC server.

It woudn't matter in my case as I'm not nor have I ever run Apple's RDC, but even then I doubt it'd make a difference; the later versions of RDC are capable of supporting VNC connections, but I believe RDC uses a different protocol, and I see no reason there'd be any kind of incompatibility between temp files even if that wasn't the case.

 

[Makosuke]

Ok, problem solved. As it turned out, a password file belonging to the user who had previously run the software was sitting at the top level of /tmp, and that may have been what was going wrong. Deleting the file directly didn't fix it, but repairing permissions (which said it fixed somethng with the /tmp directory) did.

This is exceedingly odd since I had repaired permissions not 12 hours earlier, and AFTER running the software previously. All's well that ends well, I suppose.

I did notice something very cool that perhaps is standard VNC behavior, but I haven't seen before: If I logged into one user remotely, then switched users, the VNC session remained on the original user, while the person in front of the keyboard switched to the new user. This was awesome and a half, since both people could freely control their respective user at the same time--dual simultaneous GUI logins, basically. Nice.