mesg y error

[vonleigh]

Hello,

I was trying the other day to use the write command, which worked well for me, but when the other user tried to reply, he got an error saying that i had messages deactivated.

I tried running mesg y, and here's the error:

username% mesg y
mesg: /dev/ttyp1: Operation not permitted

Which I completely do not understand, since i'm a Unix newby ;)

Also, anyone know if the talk command works? it doesn't for me.


thanks,
Vonleigh

[mervTormel]

that's very curious. have you done anything in /dev ?

could you show us your /dev/ttyp1 ?

% ll /dev/ttyp1
crw--w---- 1 merv tty 4, 1 Feb 7 17:42 /dev/ttyp1


were you running any interesting command line programs before this problem?

try this:

in terminal.app, logout of and close your terminal window(s) until there are none.

open a new terminal window ( command-n )

then try the following commands and report their results here...

% tty
/dev/ttyp2

% ll `tty`
crw--w---- 1 merv tty 4, 2 Feb 7 17:47 /dev/ttyp2

% mesg
is y

% mesg n

% mesg
is n


note: i did the above in a second terminal window (ttyp2)

[vonleigh]

Hello mervTormel,

First, thanks for the reply. I had quit terminal already, and opened a new one, so it was all done in ttyp1, here's what I get:

% ll /dev/ttyp1
crw-rw-rw- 1 root wheel 4, 1 Feb 7 18:55 /dev/ttyp1

tty
/dev/ttyp1

`tty`
/dev/ttyp1: Permission denied.

mesg
is y

mesg n
mesg: /dev/ttyp1: Operation not permitted


But then I tried :

% write myusername
write: myusername has messages disabled


thanks,
Vonleigh

[mervTormel]

why does root:wheel own your tty device?

show us your:

% id
uid=501(merv) gid=20(staff) groups=20(staff), 0(wheel), 80(admin)

% ll -d /dev
dr-xr-xr-x 2 root wheel 512 Feb 7 16:44 /dev/

[vonleigh]

Don't really know why it's owned by root, haven't really touched the unix side but to learn a bit, install php, etc.

% id
uid=501(vonleigh) gid=20(staff) groups=20(staff), 0(wheel), 80(admin)

ll -d /dev
dr-xr-xr-x 2 root wheel 512 Feb 7 16:48 /dev


thanks,
Vonleigh

[mervTormel]

oh, i wasn't accusing you, just asking a rhetorical question, like in that Dr. Phibes movie when Dr. Vesalius asks, "A key! Why a key?"

anyhow, when i open a new terminal window, i gain ownership of the ttypN file and that allows me to toggle mesg y and n

you don't seem to get that ownership, thru whatever mechanism is supposed to do it. the /dev directory permission settings look good.

that root owns that ttypN file prevents you, as username, from changing its permissions mask to no-write.

by default, it's writable, but if you toggle it, it gaks. hmmmm.

what is your umask ?

% umask
27

and show me these commands + results:

% ps axww | grep -i terminal
371 ?? S 0:55.25 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_1310721

% ll /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
-rwxrwxr-x 1 root admin 210k Dec 20 18:37 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
*

sorry about all the garrulousness, but i'm just poking at the ether at this point.

[vonleigh]

No no, I didn't take it as an accusation at all; in fact I really appreciate you taking the time to help me fix this.

% umask
22


% ps axww | grep -i terminal
329 ?? S 0:19.90 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_1835009
381 std S+ 0:00.00 grep -i terminal

% ll /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
-rwxrwxr-x 1 root admin 215164 Jan 29 18:16 /Applications/Utilities/Terminal.
app/Contents/MacOS/Terminal


BTW, what's garrulousness, although my english is pretty good, i'm not a native speaker ;)


thanks,
Vonleigh

[mervTormel]

wordy; talkative; verbose; chatty; loquacious; a lively woman is loquacious; an old man in his dotage is garrulous

welp, i'm trying to understand it myself. now i'm stabbing viciously at the ether...

how about showing us the rest of your /dev/ttyp*

% ll /dev/ttyp*
crw--w---- 1 root tty 4, 0 Feb 7 16:44 /dev/ttyp0
crw--w---- 1 merv tty 4, 1 Feb 7 19:49 /dev/ttyp1
crw--w---- 1 merv tty 4, 2 Feb 7 21:25 /dev/ttyp2
crw--w---- 1 merv tty 4, 3 Feb 7 20:10 /dev/ttyp3
crw--w---- 1 merv tty 4, 4 Feb 7 20:10 /dev/ttyp4
crw-rw-rw- 1 root wheel 4, 5 Feb 7 16:44 /dev/ttyp5
crw-rw-rw- 1 root wheel 4, 6 Feb 7 16:44 /dev/ttyp6

i just spotted something. my /dev/ttypN devices are group 'tty'. your's remains owned by root:wheel. could your tty group be amiss?

before i ask you to do some unsavory things, send us the above ll/dev/ttyp* and we'll go from there.

really stabbing away now...

[vonleigh]

Thanks for the explanation on garrulous, you learn something new every day, huh? Now dotage though, oh wait, it was dictionary.com's word of the day : )

http://www.dictionary.com/wordoftheday/archive/2001/06/02.html


I think the tty group is the problem then, they're all owned by root:

ll /dev/ttyp*
crw--w---- 1 root tty 4, 0 Feb 7 16:48 /dev/ttyp0
crw-rw-rw- 1 root wheel 4, 1 Feb 8 00:22 /dev/ttyp1
crw-rw-rw- 1 root wheel 4, 2 Feb 8 00:22 /dev/ttyp2
crw-rw-rw- 1 root wheel 4, 3 Feb 7 16:48 /dev/ttyp3
crw-rw-rw- 1 root wheel 4, 4 Feb 7 16:48 /dev/ttyp4
crw-rw-rw- 1 root wheel 4, 5 Feb 7 16:48 /dev/ttyp5
crw-rw-rw- 1 root wheel 4, 6 Feb 7 16:48 /dev/ttyp6
crw-rw-rw- 1 root wheel 4, 7 Feb 7 16:48 /dev/ttyp7
crw-rw-rw- 1 root wheel 4, 8 Feb 7 16:48 /dev/ttyp8
crw-rw-rw- 1 root wheel 4, 9 Feb 7 16:48 /dev/ttyp9
crw-rw-rw- 1 root wheel 4, 10 Feb 7 16:48 /dev/ttypa
crw-rw-rw- 1 root wheel 4, 11 Feb 7 16:48 /dev/ttypb
crw-rw-rw- 1 root wheel 4, 12 Feb 7 16:48 /dev/ttypc
crw-rw-rw- 1 root wheel 4, 13 Feb 7 16:48 /dev/ttypd
crw-rw-rw- 1 root wheel 4, 14 Feb 7 16:48 /dev/ttype
crw-rw-rw- 1 root wheel 4, 15 Feb 7 16:48 /dev/ttypf


(i don't know if it makes a difference, but this was typed into ttyp2)

And, uhm, unsavory things, I'm just happy I can use my mac and play around with unix now ;)


thanks,
Vonleigh

[pmccann]

Let me butt in here for a second with a rank long hop! (Sorry for those residing in countries where cricket is not a major sport; somewhat akin to "a slow ball right in the hitting zone that the batter saw coming about three seconds before it was thrown" if baseball's in your sporting vocabulary!)

Any chance you are using a version of the operating system prior to 10.1.2 vonleigh? I have strong memories of encountering the problem that you've described when I was using earlier versions of OS X, but have just confirmed that everything works as it should now. "mesg y" and "mesg n" just work, where they didn't previously.

If so, it might just be that your symptoms are remembrances of bugs past.

Cheers,
Paul (who just taken to talking to himself; split screens, two terminals, split personality, split brain, and with aqua I guess it's just lickety split. Aah, talk: just like the good old days! Someone posted a question about talk somewhere: now I've just got to hunt the little blighter down. Well whaddya know: it's the message I'm replying to. Hmm, pardon me while I break out of this bracketed bit...)

There: well, there's good news and bad news re talk. The good news is that talk can definitely be made to work in OS X. The bad news is that if you can't fix the above problem then I don't think you're going to be talking to too many people, 'cos you'll never be notified of an incoming talk request unless you can set your mesg to "y".

So how do you do it? Just get the ntalkd daemon running as reqd via inetd.

# sudo -s

(You've now got a root shell. Think three times before breathing.)

# vi /etc/inetd.conf (you might like to substitute another editor here)

Change the line that reads

# ntalk dgram udp wait root /usr/libexec/tcpd ntalkd

so that it's not just a comment. That is, just delete the first two characters:

ntalk dgram udp wait root /usr/libexec/tcpd ntalkd

Exit your editor, and then enter

# kill -HUP `cat /var/run/inetd.pid`

# exit
%

OK, you're mortal once again, so breathing can now be regulated automatically.

To see talk in action, just open a couple of terminal windows, type

% mesg y

in both (sorry vonleigh, your day will come!); in one of the two windows enter

% tty
/dev/ttyp3

and note the device listed (/dev/ttyp3 in the above example). In the *other* terminal window enter

% talk username ttyp3

making the obvious substitutions of your username and the device. That should kick a message into the first window, together with the string that you have to enter to answer the call: just type (note: the prompt probably isn't visible after the message has been broadcast unless you hit return...)

% talk username@localhost

And (he says confidently!) that should be it. To get to talk to someone a little more *interesting* you need to enter

% talk username@hostname.domain

(you can put in the device if you know it). Unfortunately --maybe(!)-- a lot of machines won't receive talk requests due to firewall restrictions, or the fact that they've disabled the talk daemon. Sniff, sniff, like my old work machine. So much for that idea...

Note that you can make it so that talk requests are only accepted from certain hosts. That's why you see "tcpd" in the /etc/inetd.conf line quoted above. tcp wrappers allows you to implement fairly fine-grained control over who can do what to your daemons. I'll post something about that if someone's interested, but there's a pointer to the relevant man pages in the horribly long message I posted in the identd thread about 4 days back.

Cheers have already been offered above...

Paul

[robh]

mesg y
mesg: /dev/ttyp1: Operation not permitted


I'll investigate. I'm a long time unix user.
For the record, I've done nothing in /dev.

This is with 10.1.2

[robh]

I'll investigate.

Okay, here's a fix that worked for me..

Terminal Preferences -> Shell

I changed it from


[] Use default login shell for this user
[x] Use this shell
/bin/tcsh


to


[x] Use default login shell for this user
[] Use this shell
/bin/tcsh


After making the switch, each new terminal window says "Welcome to Darwin!" (aka cat /etc/motd), under the old setting this never happened.

Clearly using the "default login shell" rather than /bin/tcsh runs a different config setup.

I'll leave it to Merv to try to trace the differences
;)

[mervTormel]

no way, man. i ain't gonna do it.

but, that 'running a different config setup' is certainly unexpected, idn't it?!

robh, thanks for shaking that out.

paul? i now call your posts 'good times'.

[pmccann]

Well that's odd. I get the same difference with respect to the motd file, but both work fine with "mesg". That is, I still get to own the /dev/ttyp* entry after logging in.

robh, if you're not bored stupid with this already, could you check that the behaviour reverts to mesg madness when you change that setting back again. That is, that the /dev/ttyp* entry when you use the /bin/tcsh shell explicitly, keeps root:wheel as owner:group instead of changing to yourusername:tty.

Cheers,
Paul

[vonleigh]

Hello,

Paul, thanks for the tip on fixing the talk feature, I will run through it right now and activate that. I am also running 10.1.2

Rob, your fix worked for me too exactly as described. Now mesg y works as it should. I tried reverting the preferences to what it was, and I get the mesg y problems again (owned by root:wheel). So I'll just leave it at the default shell.

Thanks Merv for all your help, Rob for the solution and Paul for a very interesting read and the fixing of talk ;)


Vonleigh

[vonleigh]

Hello,

Uhm... Paul, just tried getting talk to work and it still doesn't for me. I can message myself between two terminal windows using "write myusername ttyp#", but when I try "talk myusername ttyp#", It just says: "[Checking for invitation on caller's machine]" a couple of times.

I uncommented the line in /etc/inetd.conf And that's about it, anything else I'm missing? Or am I doing something wrong?


thanks,
Vonleigh

[Titanium Man]

Hey guys, I've been evesdropping and following along, since I was getting the same stuff as vonleigh, but after toggling to "Use default login shell" in Terminal/Preferences, (which fixed it and made the permissions look like the ones on MervTormel's machine) I toggled back to "Use this shell bin/tcsh" and it still works. Huh! Go figure. (I'm running 10.1.2)

[robh]

Originally posted by pmccann
robh, if you're not bored stupid with this already, could you check that the behaviour reverts to mesg madness when you change that setting back again.
Cheers,
Paul

Paul, this appears to be related to the ownership setting of the /dev/ttypX.

Spawning new terminal windows with preference set to /bin/tcsh retains the ownership. Once I spawn a tty that has a /dev/ttypX in root:wheel it remains with that ownership and "mesg y" fails.

e.g.

ls -l /dev/ttyp?
<snip>
crw--w---- 1 rob tty 4, 4 Feb 9 10:56 /dev/ttyp4
crw--w---- 1 rob tty 4, 5 Feb 9 10:56 /dev/ttyp5
crw-rw-rw- 1 root wheel 4, 6 Feb 9 10:50 /dev/ttyp6
crw-rw-rw- 1 root wheel 4, 7 Feb 9 10:56 /dev/ttyp7
crw-rw-rw- 1 root wheel 4, 8 Feb 9 10:56 /dev/ttyp8
crw-rw-rw- 1 root wheel 4, 9 Feb 8 09:52 /dev/ttyp9
<snip>



I now open a bunch of new terminal windows..


tty
/dev/ttyp5
%ls -l /dev/ttyp5
crw--w---- 1 rob tty 4, 5 Feb 9 10:57 /dev/ttyp5

tty
/dev/ttyp9
%ls -l /dev/ttyp9
crw-rw-rw- 1 root wheel 4, 9 Feb 9 10:58 /dev/ttyp9

[pmccann]

robh,

thanks for taking the time to post that: looks like it must be a bug in the way that the terminal is handling its interaction with the ttyp*'s; does this sound familiar to anyone (cf the "who" bug, in which that command lists extra ghosts because terminal can't write to the required logs with the necessary privileges. Hmm, sounding related...). I'll have a hunt around during the next few days and see if I can throw any light on the matter. At least there's a thoroughly digestible workaround!

vonleigh, I think the instructions posted above should be all you need. You did spank the daemon in the manner indicated? etc etc. Can anyone confirm that my post above worked for them (ie to get "talk talk"ing)?

ObMusic: Spirit of Eden. Very fragile, somewhat wimpy, yet incredibly beautiful in places.

Cheers,
Paul