no permission for root???

Garrett Cooper youshi10 at
Sat Aug 13 22:41:03 GMT 2005

joda pain wrote:

>I am so new(3-4 days solid) at this OS. I have tried to find good help
>to no pervail. You are the first person to answer a question direct
>and not send me to man pages or the handbook? I truly am a lost soul
>with this but I refuse to return to Win or Mac OS. If there is
>direction from an outside source I would love to recive the help. I
>have a good knowlage of window server OS. I have set up a few and
>understand there permissions.  Could you link me with someone that
>will teach me about Unix permissions/shell invocations.
>Thank the gods of cyberspace for your guidence and THANK YOU!!!
>Jody W. Payne
>On 8/12/05, Garrett Cooper <youshi10 at> wrote:
>>joda pain wrote:
>>>I have ran a fresh install on the same hard drive 3 times. I log into
>>>root without any problems. When I try to run simple commands like
>>>checking virtual consoles (/etc/ttys) I get a "Permission denied". I
>>>don't understand why this is happening. I can't access any admin
>>>properties because of permissions. What am I doing wrong??? I'm using
>>>vr. 5.4
>>>login: root
>>>NetwerksBSD# /etc/ttys
>>>/etc/ttys: Permission denied
>>>There must be someone or some place I can get an answer for this question.
>>>Right now i gather all my answers from man pages & FreeBSD Handbook
>>    Try vim /etc/ttys or ee /etc/ttys.
>>    You do realize that /etc/ttys is a flat, non-executable file,
>>correct? Are you sure you understand how Unix permissions/shell
>>invocations work? I'm sure that someone here would be willing to teach
>>you if that's the issue at hand.

    Here's a really good simple site on what Unix permissions are and I 
think it would be helpful for you based on what level you are currently 
at: <>.
    Another thing before you go chmod your /etc/ttys file... (because 
some programs may complain about incorrect permissions): your terminals 
are already running in the background. If you have a standard PC 
keyboard, you can view a lot of your virtual terminals by pressing 
ALT-F1 through ALT-F6, depending on how you setup your tty screens (and 
this is the default by the way). Your X :0'th display defaults to ALT-F7.
    One important thing to note is that in a sense Windows permissions 
can be related to Unix permissions as follows:
    Read and execute under Unix are equivalent to read and execute under 
Windows, except they are mutually exclusive in Linux, meaning I can 
specify read by itself and just be able to 'read' a text file without 
'executing' it in a shell for instance, since many files cannot be 
executed but can be read. You can also set something to executable but 
not readable, but that's essentially useless since you need to be able 
to read something in order to execute it :P...
    Users and groups are similar in Windows as in Unix. Administrators 
in Windows is equivalent to the group 'wheel' in Unix; root is the same 
as the Administrator account; and many other accounts are specialized to 
each operating system and the programs within each respective OS. 
However, there is something important to notice about the purpose of 
each account and their respective permissions in Unix versus Windows. 
Windows accounts are typically setup for either the purpose of 
interactive user login or secondary accounts for system administration, 
ie the Windows SYSTEM account. Unix expands this sort of secondary 
accounts ideality though, and as you notice when you go through 
/etc/password in a text editor, there are many other additional user 
accounts that are contained within the file than in a user list in 
Windows for instance. The reasoning is that many programs are run using 
secondary accounts in an attempt to reduce the amount of security risks 
because the ideology is if everything was owned by root and there was a 
software bug, the whole system would be accessible and as such would be 
at risk. Additional groups are created for owning /dev/ nodes. Take 
/dev/ad0s1 for instance; it is owned by root:disk in an attempt to 
reduce the possible raw disk access by unwanted groups, users, etc. 
Similar things are done with other nodes in the /dev/ directory in a 
similar attempt to increase security.
    This is a start and by searching on Google with "unix permissions 
howto" or "unix permissions explanation", you may greater learn about 
Unix permissions than I detailed with those few simple paragraphs. Shell 
information/usage is tied greatly into a Unix filesystem philosophy and 
ideologies as well, so if you get a firm grasp of what's going on with 
that, getting a grasp of what a Unix shell in general is will follow.

More information about the freebsd-questions mailing list