Workspaces/Advanced Features/Sharing

Cooperative Usage (Group Workspaces and Sharing)

When working in teams, workspaces can be shared in multiple ways.

WARNING: NEVER use chmod 777 or a+rwx on workspaces!

Do NOT make your workspace readable or writable by everyone (chmod 777, chmod a+rwx, or chmod o+rwx). This is a severe security risk:

• Anyone on the system can read, modify, or delete your data
• Malicious users can inject code into your workspace
• Your data and results become unreliable
• You violate security policies and may lose access privileges

Always use proper sharing methods: Use -g/-G flags, ws_share, or group-based permissions instead.

Important: Not all sharing methods are available on all clusters. The availability depends on:

• Filesystem type and ACL support
• Cluster-specific workspace tool configuration
• Unix group setup and permissions

If one sharing method doesn't work on your cluster, try an alternative approach. The -g and -G flags are most widely supported.

Group Workspaces

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
-g option (group-readable)					✓
-G option (group-writable)					✓

When a workspace is created with -g it becomes a group workspace that is visible to others with ws_list -g (if in same group), and is group readable:

  $ ws_allocate -g myWs 30

When created with -G <groupname> the workspace becomes writable as well, and gets group sticky bit:

  $ ws_allocate -G projectgroup myWs 30

The group can be specified in the ~/.ws_user.conf file as well. See Reminders & Configuration.

Important: Group members can extend group-writable workspaces (created with -G) even if the original creator is absent:

  $ ws_allocate -x -u <username> <workspace_id> <days>

This requires group write access to the workspace. This is useful when the workspace owner is unavailable and the workspace needs to be extended.

Recommendations:

• Use -g when team members only need to read your results
• Use -G for collaborative work where everyone writes data
• Set groupname in ~/.ws_user.conf if you always work with the same group

Sharing with ws_share

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
ws_share command (ACL-based)					✓

With ws_share you can share workspaces with users outside your group, using ACLs (if supported by underlying filesystem).

Note: This feature requires ACL support on the filesystem. If ws_share doesn't work on your cluster, use manual ACL commands (setfacl) or fall back to Unix group permissions.

Share workspace with users

  $ ws_share share myWs username1 username2    # Grant read access to one or more users
  $ ws_share share -F filesystem myWs user1    # Share on specific filesystem

Unshare workspace from users

  $ ws_share unshare myWs username1            # Remove access from specific user(s)
  $ ws_share unshare-all myWs                  # Remove access from all users

List users with access

  $ ws_share list myWs                         # Show all users with read access

These operations are applied to all files and directories in the workspace.

Options

• -F <filesystem>, --filesystem: Specify the workspace filesystem
• -h, --help: Show help message

Recommendation: Use ws_share for selective sharing with individual users, especially when they are not in your Unix group.

ACLs: Access Control Lists

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
setfacl/getfacl (ACLs)					✓

ACLs (Access Control Lists) provide fine-grained permission control beyond standard Unix permissions. They allow sharing with specific users and groups, and support default ACLs that new files automatically inherit.

Note: ACL support varies by filesystem. Not all clusters support ACLs on workspace filesystems. If ACL commands fail, use regular Unix permissions instead.

Key advantages

• Share with specific users (not just groups)
• Default ACLs - new files automatically inherit permissions
• More flexible than Unix permissions

Note: ACLs take precedence over standard Unix permissions. View ACLs with ls -l (shown as "+" after permissions).

Quick Examples

Set workspace path in variable:

  $ DIR=$(ws_find my_workspace)

View current ACLs:

  $ getfacl "$DIR"

Important note on syntax: In all commands below, user: and group: are setfacl keywords. Replace username with the actual user login name (e.g., alice, jdoe) and groupname with the actual Unix group name (e.g., bw11a000).

Grant read-only access to a user:

  $ setfacl -Rm user:username:rX,default:user:username:rX "$DIR"
  
  # Example with actual username:
  $ setfacl -Rm user:alice:rX,default:user:alice:rX "$DIR"

Grant read-write access to a user:

  $ setfacl -Rm user:username:rwX,default:user:username:rwX "$DIR"
  
  # Example with actual username:
  $ setfacl -Rm user:jdoe:rwX,default:user:jdoe:rwX "$DIR"

Grant read-only access to a group:

  $ setfacl -Rm group:groupname:rX,default:group:groupname:rX "$DIR"
  
  # Example with actual groupname:
  $ setfacl -Rm group:bw11a000:rX,default:group:bw11a000:rX "$DIR"

Remove all ACLs:

  $ setfacl -Rb "$DIR"

Key Options

• -R: Apply to all files and subdirectories
• -m: Modify (add or change ACL entries)
• -b: Remove all ACL entries
• user:username:rwX: Set permissions for specific user (replace username with actual login)
• group:groupname:rwX: Set permissions for specific group (replace groupname with actual group)
• default: prefix: New files inherit these ACLs automatically
• r: Read permission
• w: Write permission
• X: Execute only on directories and already-executable files (capital X)

Important: Always use the default: prefix to ensure new files get the correct permissions automatically.

Recommendation

Always prefer ws_allocate -G or ws_share first. Use manual ACLs only for complex scenarios like:

• Sharing with specific users outside your group
• Different permissions for different users
• Fine-grained control not possible with -G or ws_share

Regular Unix Permissions

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
chmod/chgrp (Unix permissions)	✓	✓	✓	✓	✓

Use standard Unix permissions with chmod and chgrp when you and your collaborators share a common Unix group.

CRITICAL WARNING:

• NEVER use chmod 777 or a+rwx - makes your data accessible to everyone on the system
• NEVER use chmod o+rwx or chmod o+w - allows anyone to modify or delete your files
• Only set group permissions (g+r, g+w) for your specific research group

Quick Examples

Set workspace path in variable:

  $ DIR=$(ws_find my_workspace)

Read-only access for group:

  $ chgrp -R mygroup "$DIR"
  $ chmod -R g+rX "$DIR"

Read-write access for group:

  $ chgrp -R mygroup "$DIR"
  $ chmod -R g+rswX "$DIR"

Key Options

• -R: Apply to all files and subdirectories
• g+r: Group read permission
• g+w: Group write permission
• g+x: Group execute permission
• X: Execute only on directories and already-executable files (capital X)
• s: Setgid bit (set-group-ID) - new files inherit the directory's group ownership

Important: The setgid bit (g+s) ensures new files belong to the correct group, but their permissions depend on your umask. With the default umask (0022), new files will NOT be group-writable automatically. You must either:

• Set umask 0002 in your shell so new files are group-writable by default, OR
• Manually run chmod g+w on new files, OR
• Use ACLs with default: entries (which override umask and handle permissions automatically)

Recommendation

Always prefer ws_allocate -G groupname over manual Unix permissions. It handles everything automatically and correctly, including the sticky bit and proper permissions on all new files.

Use manual chmod/chgrp only when -G is not available on your cluster or for fixing permissions on existing data.