Structure and Permissions

How the Research File Store is organised and how you control access to it.

A new Research File Store (RFS) area will be named after the project which was registered. The access groups which provide privileges to use the area will have names derived from the project name too.

In the examples below the project is called Project and is accessed as:

  • R:\Project from Windows 7 PCs on campus
  • /rfs/Project from Linux systems

Access Permissions

The Research File Store has been designed to share research data. By default, all users of an RFS share have at least read-only access to all areas of that share.

The service has not been designed to allow denial of access to directories or folders within a share to specific users.

Two groups are created to control access to each storage area:

  • RAM-RFS-Project-admin - contains the research lead and any alternate contacts defined during registration. The group will have permission to add, modify and delete any content within the storage area.
  • RAM-RFS-Project - contains everyone (including anyone in RAM-RFS-Project-admin) who requires access to the storage area. The group will have permission to read any content. In addition it will have permission to create new files within the Shared folder.

If you need to add users to either group, contact the IT Service Desk.

Directory Structure

Your storage area will contain the following folders by default:

  • Shared - all users of the area can read from and add new content to this folder. Note that new content will only be readable to RAM-RFS-Project members, not writeable. It will be necessary to modify the permissions if you require RAM-RFS-Project write access to other users' files and folders.
  • User folders - each registered user of the storage area has a folder of their own at the top level.   Each user has read/write access to their own folder and the rest of the users of the storage area have read access only.
Project Folder

You are not obliged to use the directory structure we provide. Users in the group RAM-RFS-Project-admin have the ability to create new folders at this top level.

It is important to note that any new folders created at the top level will by default only have read access for other members of the project (i.e. users in the group RAM-RFS-Project). It will be necessary to modify the permissions of new top-level folders if write access is required for anyone other than members of RAM-RFS-Project-admin.

Control access on Linux

The RFS file system is not a normal Linux system. The underlying security model is based on an extensive set of access controls. The set of access controls assigned to a file or directory is called the Access Control List (ACL). These are much richer than standard Linux permission modes and there isn't a simple mapping between modes and ACLs.

When a new storage area is created, default ACLs are set at the top level and inherited by new files and directories created after that. In most cases these will be adequate and there will be no need to modify the ACLs. However the output from ls -l on a Linux client will look incorrect, for example:

> cd /rfs/Project/Shared
> mkdir newdir
> ls -ld newdir
d--------- 2 ljg2 it_staff 2048 2012-08-03 12:29 newdir

This suggests that nobody has access to the directory, because ls cannot show the full ACL. You should use the command nfs4_getfacl instead:

> nfs4_getfacl newdir
A:fdg:it-researchcomputing@le.ac.uk:rwaDdxtTnNcCoy
A:fdg:ram-rfs-project-admin@le.ac.uk:rwadxtTnNcCoy
A:fdg:ram-rfs-project@e.ac.uk:rwaDxtncy

This shows that four access control entries have been inherited automatically from the parent directory, with appropriate privileges for the project groups.

You can modify ACLs with the command nfs4_setfacl, or use the Security tab in the Windows Properties.

Tips for managing permissions from Linux:

  • Identities in ACLs should be in lower case (e.g. ram-rfs-project@le.ac.uk, not RAM-RFS-Project@le.ac.uk).
  • Beware when using chmod/chgrp to set privileges. The resultant ACLs may not be appropriate for Windows clients. Use nfs4_setfacl instead unless you're confident that you understand the consequences.
  • Think carefully about inheritance when adding or modifying ACLs. With planning, a single new directory can be created with an appropriate ACL which will apply to everything created within it automatically.
  • Never add deny access controls. Access is denied unless granted, so access privileges should just be built up from a set of access grants, not subtracted from with denies.

The default ACLs should be adequate in most cases and shouldn’t need to make any modifications. However if you have extra requirements and need any help, contact the IT Service Desk.

Share this page: