SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm trying to give serial port access to my user account by adding it to the uucp group. I noticed the udev rules files has an entry that creates the symlink /dev/ttyS0 to /dev/tts/0 - from what i understand, each should be owned by root:uucp.
but after failing to run minicom, i noticed the the /dev/ttyS0 symlink is owned by root:root. my question is, should i manually change this? or have i missed something?
I don't think the group uucp has got anything to do with it.
symlinks are usually lrwxrwxrwx, so the owner and group of a symlink are largely irrelevant, its the file the symlink points to that matters. Of course you could test if permissions were your only problem by testing as root.
Have you got a driver loaded for your serial device?
look for 8250 in the output of lsmod.
if its not there, try
then when your serial device is connected, try minicom again.
If there is a permissions problem, you can test by temporarily modifying the perms on the device with say
chmod 666 /dev/thedevice
if that makes a difference, then you could look at modifying the perms in your udev rules
maybe i was not specific. my serial connection is working fine using root account. i was trying to get it to work on my user account. the owner of /dev/ttyS0 link is root:root (the udev rules should have set it to root:uucp, just like the actual device file /dev/tts/0) - so, even when i added my user account to uucp group, minicom simply fails.
so, my point is, do i have to manually "chown root:uucp /dev/ttyS0"?
I didn't realize you had it working for root already.
I see what you mean about the uucp group.
I can't understand why putting yourself in the uucp group doesn't work, but I tested it myself and found the same thing.
Well, I remember what I did to get it working for users, though it allows all users access which may or may not concern you.
if you create a file called 90-local.rules in
it will supercede the 40-slackware.rules to allow access to users. This is preferable to modifying 40-slackware.rules directly, as your local.rules file will survive udev updates, and also you know where to find changes you made to your system easily.
edit: by the way, you can update the udev configuration without rebooting, by running
as root, after you have saved your changes to udev rules
thanks again for the reply. that's the thing about udev - i never really understand the rules file. the way i read the file, i thought the symlinks should already be as i expected (owned by root:uucp). if that is the case, i just thought i want to know why has it changed? what made the changes? or did i mis-interpret it?
i'll try adding a local rules file as a last resort. i just wouldn't want to add anything to what is already there unless i really need to
most surprising is that this change survives rebooting!
this implies to me that there is a bug in the implementation of udev, that doesn't [always] change the group assignation. But that still doesn't explain to me why tts1-3 get the correct group.
Of course there are variables that I may not have considered.
I suggest that you chown /dev/tts/0 as I did, and see what happens.
One other point. You keep mentioning the symlinks. I really don't think this is relevant.
if you do
ls -l /dev/ |grep ^l
you will see that there is not a single symlink in /dev that isn't
You're right... I was so wrapped-up with the owner thingy to notice about the permission - thanks!
hmm.. still, that doesn't solve my problem. my minicom.users file has an "ALL" entry - which I assume is okay for all users. well, i guess as far as the topic is concerned, this thread is done
i'll check for other minicom settings to see what else i can tinker with
EDIT: minicom is now working for my user account! i think it was my mistake of not doing more testing. i added my user account to the uucp group using kuser - and tried minicom from an opened console (which may not have updated the group change?). anyways, all is working now. just thought i should mention it to give this thread a real closure
Last edited by lordwolf; 05-26-2008 at 10:12 PM.
Reason: Added Info