New Linux Users | pitfalls and differences | Win/Linux

Some Pitfalls and differences for new Linux users especially coming from Windows.

  1. Linux file system is case sensitive, this you have to take in consideration, always.
    1.1 a small example if you search with grep (see man grep):
    -i, --ignore-case
    Ignore case distinctions in patterns and input data, so that characters that differ only in case match each other.
  2. Path’s divider is forward slash / in *nix based OS’s. You need back slash \ only as an escape character and/or when you have to be “compatible with older Windows versions” like old samba paths etc.
  3. Partitions do not get an Alphabetical character like C:, D: etc.
    3.1 Your partitions can be displayed with lsblk, or managed with sudo cfdisk as an example.
    They are shown in the /dev directory of the file system. To access them in a path they have to be mounted (see man mount).
  4. The “Administrator” account is named root in Linux.
    4.1 Your account needs to be a member of the wheel group in order to perform administrative tasks. By default the first user added is made a member of the wheel group.
    The wheel group is listed in /etc/sudoers file and given admin privileges. To edit the # commented options, you can use the command visudo to change the /etc/sudoers file.
    In the GUI when adding a user, there is a tick to mark it as an administrator (which adds that user to thewheel group).
    To give new users certain admin privileges to control a program or a service etc, it is a good practice to create a file under the /etc/sudoers.d directory. This keeps the additional sudoers rules for that user or group nicely separated in a file of your choice for easy management.
    4.1.1 To get a Terminal like root@yourhostname you can use su - and enter the root user’s password or sudo -i and enter your personal account’s password. On Fedora Linux, the root user’s password will need to be set with sudo passwd root before su - will work.
  5. Linux uses POSIX-style permissions
    5.1 Other filesystems like fat, fat32, exFat and ntfs don’t(easily) support these conventions so their permissions are determined by how they are mounted. If you are having trouble writing to one of these filesystems, check your mount options.
  6. Whether or not a file is executable is not determined by the file extension name (.com, .exe, .bat, etc.)
    6.1 A file’s permission mode must be set to executable before it can be run directly. Use chmod +x <filename> to mark a file as executable. Scripts can also be executed by using bash filename.
    6.1.1 On terminals that support color, executable files are often color-coded green. Otherwise, you can use the list command’s “long format” option to see if a file is marked executable (i.e. ls -l). Files that are marked executable will have one or more “x” characters in the first column of the output of ls -l.
  7. The current directory may not be in the default search path for executable files. To see what directories are are in your path type echo $PATH
    7.1 In order to run an executable that is not located in your search path you must prefix the file name with ./ (e.g. ./ or use the absolute path (e.g. /home/username/
  8. Environment variables use the dollar sign.
    8.1 When accessing environment variables, prefix them with $ instead of % (e.g. echo $PATH).
    8.2 When assigning to a variable, do not leave spaces around the equals sign (e.g. PS1="[\$PWD]\\$ ")
  9. Linux follows the Filesystem Hierarchy Standard (FHS)
    9.1 As example, user data is stored in /home/username ( e.g. echo $HOME; absolute path).
    9.2 The relative path is shown as ~ (e.g echo ~/ to resolve it to an absolute path). Just cd as a command brings you back to your home directory. pwd always prints the current working directory on the screen.
  10. Installed programs do not use a system database or “registry” to store their configuration data.
    10.1 Programs usually store their settings in a file or directory by their name under /etc (e.g. /etc/ssh) for “global” settings that affect all users on the system and/or under the user’s home directory (e.g. /home/john/.ssh) for “per-user” settings that only affect one user. If the same option has different values in the global and per-user config files, the per-user value almost always wins.
    10.1.1 Configuration files are almost always stored in a plain-text format that can be edited with any text editor (e.g. nano). If you want to verify that a file is in plain-text before trying to open it, you can use the file command (e.g. file /etc/hosts).

I saved the Topic as a Wiki. Advanced users can edit and add some differences/pitfalls.
Keep in mind to be short. Mention man pages to train new Linux users how to use the built in manual, the man or info pages (see man man, man info or viz versa)


@glb thanks for your thoughts.

I would formulate it so:

Your account needs to be a member of the wheel group. The wheel group is listed in /etc/sudoers file.
To edit the # commented options, you can use the command visudo to change the /etc/sudoers file.

For new users, to control a program or a service etc, it is a good practice to list a file under the /etc/sudoers.d directory. So the additional sudoers rules are nice separated in a file of your choice, in order to be able to run sudo.

What do you think ?

@ilikelinux: Sounds good to me. Feel free to add/remove/change whatever you like. What I added was only a few quick ideas that I came up with. I’m sure there is plenty of room for improvement. :slightly_smiling_face:

1 Like

@ilikelinux I think your suggestion for the change is a very good idea. Previously there was no documentation to encourage users to create a file there with rules for individual users and many have tried editing the /etc/sudoers file each time with varying results.

If they were to instead use a file that was specific to that user account in /etc/sudoers.d it is very easy to see that a specific user has a problem, what it is, and tailor the entries without potentially affecting the entire system and/or other users use of sudo.


Maybe an example should be provided inline as well for convieniance? E.g.:

# Allows the account "john" to run any command using sudo
john ALL=(ALL) ALL
1 Like

I never made it this way … but as @glb mentioned it, i remembered to read this in other *.d folders. I was thinking a fictive file with commented out rules and a short description on the top would be a good thing. I will check it/search where I saw it and will make a proposal, to add in future versions it to /etc/sudoers.d/ that it not keeps empty :wink:

BTW do you have an idea why the wheel group and from where it comes?

Do you mean in /etc/sudoers.d/ add a file as example or above on point 4.1 ?

If on point 4.1, it would be better just show how to add the user to the group wheel.
To check who is wheel is as easy as:

$ cat /etc/group |grep wheel

It’s up to you. My personal preference would be to configure the sudo application directly rather than relying on the legacy wheel group. But I can see your point about it being easier to just add people to the wheel group since there is a built-in command for that.

Not needed since members of the wheel group already have that exact syntax.

Not all sudo users would need that and it would imply that it is acceptable for all users to be able to do everything.

This is a bit confusing, because there are administrator accounts, there just isn’t an account named Administrator by default. In the GUI when adding a new user, there is a tick to mark it as an administrator (which adds it to wheel, etc.). So saying there isn’t one is even more confusing, as that would be what someone did when setting up the first run.

1 Like

Also, about 50% of these are about working in the command line, and assume a bit of familiarity with it. I’m not sure that new users are necessarily aiming to use it, so I think this needs a bit of framing for context.


Thanks for your input @qulogic . I agree and already made a change

I asked my self the question why wheel (naming).
The answer is:

The term was derived from the slang phrase big wheel, referring to a person with great power or influence.

I agree, my first intention was just to post some main topics where the user should be motivated to make searches or read the man pages. But I was glad to see the participation, and so i think to write this things down is not a bad idea.
The whole topic could be a good exercise for someone who wants to start writing docs, and put this points in a quick doc.

As a site-note:
The therm Linux was meant to describe the kernel as Linus Thorvald created it. Today we do refer to a whole Distribution incl. Desktop environments. Just about this 50% you mentioned.

I got motivated to do this Topic because I helped a new user who came from Windows/Mac and had some doubts.

The wheel group has been around for many years on unix style systems, even long before the Linux kernel was developed.

The default installation of Workstation automatically sets up the first user as a member of the wheel group since it no longer assigns a password to the root user and sudo is the only way to have superuser privileges. When other users are added (must be done by an administrator) they also may be made an administrator but are not by default.

I was looking at the Docs recently and see that they are out of date for the current releases and configuration so will task myself with updating them. I think both the installation docs and the administration docs need updated.

As we all should know, root access should be limited to a very few individuals on most systems. By using sudo and the configuration files in /etc/sudoers.d/ access can be tailored to allow others specific limited functions but still restrict general superuser access to those who actually need it.

Those using sudo and the commands given are logged, while commands given while logged in as root (or after using sudo su -) are not logged.

Actually, there is an option in Anaconda to assign a root password, but it’s not mandatory and at first glance, it looks like it’s not usable. I know, because I bought this laptop late last year, and installed F 35 (Xfce Spin) on it and it’s had a root password from the time I installed it, and my regular user has never been in wheel because I don’t need or use sudo.

It may be so on xfce spin, but the default workstation iso does not give that option during the install. The first boot may, but I did not see it when I did a new install in a VM yesterday. I repeated that install today to check and confirmed that the Workstation install does not give an option at any point during the install or first boot to create a password for the root user.

I can only assign a password to the root user by using sudo.

I sit corrected. However, if some of the spins allow (not require) setting the root password, the ability is there. Maybe it should be available for all installs, including the workstation, but clearly marked as optional. Of course, this isn’t really the place to discuss it.

I think it would be, since it is something new users might need to know.

Probably it should go into section 4, where other root issues are discussed. However, before we change it, somebody should check all of the spins to see if there’s an option in Anaconda to set a root password, even it it looks like it’s been disabled. (That’s what it’s like in the Xfce spin.)

I mean, the Fedora Discussion forums have that name for a reason. It’s a nice-to-have here in case a new user is searching for something like it, but this thread is definitely more suited there and the results become part of either the Docs or the Wiki.

I do confirm, that in Mate Spin there is the option to set the Root password. I was surprised while install the workstation not finding the option.