>> "s" == servis <[EMAIL PROTECTED]> writes: s> | Strange it works as root. As you can see, you don't have a s> | /etc/ppp/options file. Create one and try again.
s> This fix doesn't seem like the right way to fix this problem. Why s> would running it as root NOT fail when the options file is not present s> and when run as a user it needs to have the options file present. Don't know. This *is* strange, just as I said. s> Well, now the error message goes away but it just exits without doing s> anything, assuming because the options file is empty. No. The options file may be empty. s> A strace shows that it is trying to execute '/usr/sbin/pppd call s> provider', which is what /usr/bin/pon does, but it fails. s> [pid 1219] execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "call", "provider"], [/* 36 vars */]) = -1 EPERM (Operation not permitted) s> If I explicitly type in '/usr/sbin/pppd call provider' the log shows an s> entry of s> 'Aug 26 08:57:36 brian pppd[1221]: pppd 2.3.5 started by servis, uid 6262' s> but no error message is returned and nothing happens. Now I am *really* confused. In another mail you said: % id uid=6262(servis) gid=6262(servis) groups=6262(servis),20(dialout),29(audio),30(dip) % ls -l /usr/sbin/pppd 105 -rwsr-xr-- 1 root dip 105532 Jun 18 19:59 /usr/sbin/pppd* This is OK. If permissions are wrong, you should get a $ /usr/sbin/pppd su: /usr/sbin/pppd: Permission denied (try this please) Maybe you did the "adduser name dip" during the current session? Then you should login again. (and try /usr/sbin/pppd again. Different output/logs ?) Ciao, Martin -- from a 1996 Microshit ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right!