Linux File Storage and Permissions

Every EECS Linux account has an associated home directory (aka “home area”) where all files are stored by default. When you log into an EECS Linux system, whether directly or via remote access such as SSH or RealVNC, your account's home directory is automatically attached (“mounted”) to /home/username. So if your username is “jruser” all your files are now mounted at /home/jruser.

Your files are not actually stored on the hard drives or other permanent storage attached to the login systems such as the lab computers. Instead, your files are stored on a file server in the EECS datacenter and are remotely accessed over the network.

If you are a member of a professor's research group or have been otherwise given special access, you may be able to use a directory in one of the two storage areas maintained by EECS:

• /research - Sub-directories in this hierarchy are RAID-protected and backed up nightly.
• /storage - Sub-directories in this hierarchy are RAID-protected but not regularly backed up.

To access one of these directories, you can cd into the appropriate sub-directory. For example, if you have been given access to the foo research directory, you would type:

cd /research/foo

Please note that these directories are only viewable after they are accessed. If you cd into /research you will not see a full listing of all available research directories. However, if you cd into /research/foo then the foo directory will appear.

The ls -l command shows file permissions in the leftmost column of the output. Permissions are displayed in three blocks:

• User Permissions ~– permissions that apply to the file's owner
• Group Permissions ~– permissions that apply to the file's group
• Other Permissions ~– (often called “world” permissions) permissions that apply to everyone not covered by the above. Note that this means a file that is other-readable but not group-readable is not readable to a member of the group.

Permissions are:

• r ~– Readable
• w ~– Writable
• x ~– Executable (or being able to enter a directory)

There are additional permissions that can be set such as setUID and setGID, the “sticky bit”, etc. For more information on how to use these and what they mean, please see one of the many guides to file permissions, for example:

• The Wikipedia entry on File_system_permissions#Traditional_Unix_permissions
• Linux.com's guide to Understanding Linux File Permissions

jruser:hydra9 ~> ls -l
-rwxr-x---. 1 jruser jruser     1024 Apr  9 13:20 myFile

- rwx r-x —. jruser jruser 1024 Apr 9 13:20 myFile

Under normal circumstances, you cannot change the owner of a file. Any file you create will generally be owned by your user account. You cannot “give away” files to others. However, you can usually change the group ownership of a file to any group of which you are a member.

If you are unsure what to what Unix groups your account belongs, try running the “id” command:

$ id
uid=19417(jruser) gid=2405(jruser) groups=2405(jruser),2270(somegroup),2483(another)

In the above example, the “jruser” user account has a default group of “jruser” and is also a member of “somegroup” and a group named “another”.

To change the group ownership of a file (for example to give other members of a group permission to read it), use the chgrp command. For example:

14:12:07 jruser@hydra5
~$ ls -l testfile
-rw-------. 1 jruser jruser 4 Apr  3 14:12 testfile

~$ chgrp somegroup testfile

~$ ls -l testfile
-rw-------. 1 jruser somegroup 4 Apr  3 14:12 testfile

~$ chmod g+r testfile

~$ ls -l testfile
-rw-r-----. 1 jruser somegroup 4 Apr  3 14:12 testfile

In the above example, the user “jruser” changed the group ownership of file testfile to group “somegroup” with the chgrp command and then gave the group read permission on that file with the chmod command.

If you want to change the group ownership of an entire directory and all its files and subdirectories, you can use the -R (recursive) option to chgrp. Be Careful: If you specify the wrong group or directory, you might inadvertently give access to more than you intended or remove access for authorized groups. For example, to change all the files in the “testdir” directory:

~$ ls -l testdir
total 8
-rw-------. 1 jruser jruser 6 Apr  3 14:19 file1
-rw-------. 1 jruser jruser 6 Apr  3 14:19 file2

~$ chgrp -R somegroup testdir

~$ ls -l testdir
total 8
-rw-------. 1 jruser somegroup 6 Apr  3 14:19 file1
-rw-------. 1 jruser somegroup 6 Apr  3 14:19 file2

~$ chmod g+x testdir

~$ chmod -R g+r testdir

~$ ls -l testdir
total 8
-rw-r-----. 1 jruser somegroup 6 Apr  3 14:19 file1
-rw-r-----. 1 jruser somegroup 6 Apr  3 14:19 file2

In this example, the user changed the group ownership for the entire directory testdir to some group by using the -R (recursive) option to chgrp. Additionally, the user changed the permission on testdir to “executable” so that group members can see the contents of that directory. The user then changed the permissions on the directory and all its files to “readable” by the “somegroup” group with the recursive option to chmod. Now all members of the “somegroup” group should be able to see the contents of “testdir” and read the contents of all its files.

For a rich permissions model which allows fine-grained access to files and directories, see NFSv4 Access Control Lists.

In most situations, you do not want your EECS files to be readable or writable by other users on the system. EECS home directories are not meant as a place to share files with others. Thus, by default, files are not accessible to anyone but the end user. In a system (like is the case with EECS) where User Private Groups are in effect, even changing the group permission on a file does not make it accessible to other users.

Files in your webhome directory will need to be readable but should not be writable by other users. Under certain circumstances, it may be necessary to give other users access to some of your EECS files or directories. Below are some scenarios and the recommended way of granting access:

Files that need to be shared between members of a research group should be stored in the appropriate /research directory.

Each faculty members may request a /research directory for their group. Please contact the EECS IT Staff for more help.

Group ownership of research files should be that of the associated Linux group. So, for example, if you are a member of a research group named Foolab, you should store all your research-related files in /research/foolab and the files should be group-owned by the foolab Linux group:

jruser:hydra9 /research/foolab>ls
total 8
drwxrwx---. 3 jruser foolab    42 Aug 25  2005 important/
drwxrwx---. 2 jruser foolab     6 Feb  6  2013 more_important/
-rw-rw----. 1 jruser foolab  2693 Oct 21  2016 somefile

If you have short-term projects (e.g. for a class) which require sharing files with other users, you can request a special Linux group to be created for your project. Please contact the EECS IT staff with the following information:

• Description of the project
• Members of the project group
• Faculty sponsor
• Project duration
• File storage requirements

The EECS IT staff will help you design the right kind of solution.

If you need to quickly share a file with others, consider using one of UT's recommended cloud file storage options such as Microsoft OneDrive or Google Drive File Stream. You can access these from any web browser on our Linux systems.