Workspaces/Advanced Features

This document covers advanced features and detailed configuration options for the HPC workspace tools. For basic daily usage, see the main Workspaces guide.

Complete Command Reference

Task	Command
Create workspace for 30 days	ws_allocate myWs 30
Create with custom email	ws_allocate -m custom@example.com -r 3 myWs 30
Create group-writable workspace	ws_allocate -G groupname myWs 30
Create on specific filesystem	ws_allocate -F filesystem myWs 30
List all your workspaces	ws_list
List by remaining time	ws_list -R
List available filesystems	ws_list -l or ws_find -l
Find workspace path	ws_find myWs
Extend workspace by 40 days	ws_extend myWs 40 or ws_allocate -x myWs 40
Share with another user	ws_share share myWs username
List shared users	ws_share list myWs
Send calendar reminder	ws_send_ical myWs user@example.com
Release workspace	ws_release myWs
List restorable workspaces	ws_restore -l
Register workspace links	ws_register ~/workspaces

Multiple Filesystem Locations

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
-F option (multiple filesystems)	✓	✗	✗	✗	✗

Some clusters offer multiple filesystem locations for workspaces with different characteristics:

bwUniCluster 3.0:

• Default workspace filesystem (Lustre)
• Flash-based workspace filesystem (ffuc) - for KIT/HoreKa users only
  • Lower latency and better performance for small files
  • SSDs instead of hard disks
  • Shared between bwUniCluster 3.0 and HoreKa

Example creating workspace on flash filesystem:

  $ ws_allocate -F ffuc myworkspace 60

Use ws_list -l or ws_find -l to see available filesystem locations on your cluster.

Detailed ws_allocate Options

Basic Usage

Execution of:

  $ ws_allocate myWs 30

e.g. returns:

  Workspace created. Duration is 720 hours. 
  Further extensions available: 3
  /work/workspace/scratch/username-myWs-0

The command returns the path to the new directory, which can be captured in a variable:

  $ SCRDIR=$(ws_allocate myWs 10)

Important: Creating a workspace a second time with the same command is a no-operation - it always returns the same path. This makes it safe and encouraged to use such a line in batch jobs which are part of a series of jobs working on the same data, no matter if the job was running before or not.

All Options and When to Use Them

Option	Description	When to Use
-F <filesystem>	Specify the filesystem where the workspace should be created	Optional - Most clusters have only one default filesystem. Use only when you need specific storage characteristics (speed, capacity) or to balance load across multiple filesystems. List available locations with ws_list -l or ws_find -l
-g	Create a group-readable workspace	Recommended when working in a team and others need to read your data. The workspace will be visible to group members with ws_list -g
-G <groupname>	Create a group-writable workspace with sticky bit	Recommended for collaborative work where team members need to write data. Ensures all created files belong to the group. Can be set as default in ~/.ws_user.conf
-m <mailaddress>	Set email address for reminders	Optional - Email addresses come from your identity provider. Only use this option to override with a different address. Can be set as default in ~/.ws_user.conf
-r <days>	Set reminder to be sent n days before expiration	Optional - Email reminders are sent automatically. Use this only to customize when the reminder starts (e.g., 3, 5, or 7 days before). Can be set as default in ~/.ws_user.conf
-x	Extend an existing workspace	Use when you need more time. Each extension consumes one of the available extensions
-u <username>	Used with -x to extend another user's workspace	Use when a group member is absent and their shared workspace needs extension. Requires group write access
-c <comment>	Add a comment to the workspace	Use to document the purpose of the workspace for yourself and collaborators
-d <duration>	Duration in days (alternative to positional argument)	Use if you prefer explicit option syntax: ws_allocate -n myWs -d 30
-n <name>	Workspace name (alternative to positional argument)	Use if you prefer explicit option syntax: ws_allocate -n myWs -d 30

Duration Settings

If you do not specify a lifetime, a default lifetime will be used (typically 1 day). The maximum lifetime may be limited by the operations team. If you specify a longer lifetime, it will be capped to the maximum, and you will see a message that it was changed.

For more information read the program's help: $ ws_allocate -h or man ws_allocate

Advanced ws_list Options

Beyond the basic options shown in the main Workspace guide, ws_list supports additional sorting and filtering:

• -N - Sort by name (alphabetical)
• -C - Sort by creation date
• -t - Terse format
• -v - Verbose format with all metadata
• -r - Reverse sort order
• -F <location> - List workspaces on specific filesystem only
• -g - List group workspaces (if you're in the same group)
• -l - List available filesystem locations

To list expired workspaces, see Restore an Expired Workspace.

For more information: $ ws_list -h or man ws_list

Advanced ws_find Options

ws_find can search workspaces on specific filesystems:

• -F <filesystem> - Search workspace on specific filesystem
• -l - List valid filesystem names

Advanced ws_extend Options

Beyond the basic extension shown in the main Workspace guide:

• -F filesystem - Extend workspace on specific filesystem
• ws_allocate -x - Alternative command for extension
• You can shorten workspace lifetime even if no extensions are available
• Group members can extend group workspaces: ws_allocate -x -u <username> <workspace_id> <days>

Update reminder only (without extending):

  $ ws_allocate -r <days> -x <workspace> 0

Getting Reminders

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
Email reminders	✓	✓	✓	✓	✓
ws_send_ical (calendar reminders)	✓	✗	✓	✗	✗

Email reminders: Sent automatically using email addresses from your identity provider. You can customize the reminder timing with -r <days>:

  $ ws_allocate -r 7 myWs 30                          # Reminder 7 days before expiry
  $ ws_allocate -r 3 -m custom@example.com myWs 30    # Custom timing and different email address

Calendar reminder (bwUniCluster 3.0, Helix):

  $ ws_send_ical <workspace> <email>

User defaults in ~/.ws_user.conf (YAML format):

mail: reach@me.here       # Optional - only if you want to override the email from identity provider
duration: 10              # Default workspace lifetime
reminder: 3               # Days before expiration to send reminder
groupname: mygroup        # Default group for -G option

Example ~/.ws_user.conf Configuration

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
~/.ws_user.conf configuration file	✓				✓

Here's a complete example configuration file that sets useful defaults:

# ~/.ws_user.conf - Workspace tool defaults
# This file uses YAML syntax

# Email address for expiration reminders (optional)
# If not set, email from your identity provider is used automatically
# Only uncomment this line if you need to use a different email address
# mail: custom.email@example.com

# Default workspace duration in days
# Set this to your typical workspace lifetime to avoid typing it every time
duration: 30

# Reminder timing in days before expiration
# You will receive an email this many days before workspace expires
# Recommended: 3-7 days to give yourself time to extend or backup data
reminder: 5

# Default group name for collaborative workspaces
# If you always work with the same group, set this to avoid typing -G groupname
# Uncomment and set your group name below:
# groupname: bw16e001

To create this file:

  $ nano ~/.ws_user.conf

Then paste the configuration above and adjust the values to your needs.

Benefits of using ~/.ws_user.conf:

• Avoid typing the same options repeatedly
• Ensures consistent settings across all workspace operations
• Simplifies commands: ws_allocate myWs instead of ws_allocate -r 5 myWs 30
• Automatic group collaboration setup when groupname is set

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.

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 allow a much more detailed distribution of permissions but are a bit more complicated and not visible in detail via ls. They have the additional advantage that you can set a "default" ACL for a directory (with a -d flag or a d: prefix) which will cause all newly created files to inherit the ACLs from the directory. Regular Unix permissions only have limited support (only group ownership, not access rights) for this via the suid bit.

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

The examples will assume you want to change the directory in $DIR. If you want to share a workspace, DIR could be set with DIR=$(ws_find my_workspace)

Best practices with respect to ACL usage

1. Take into account that ACLs take precedence over standard Unix access rights
2. The owner of a workspace is responsible for its content and management
3. Use ACLs for fine-grained control when standard Unix permissions are insufficient

Please note that ls shows ACLs on directories and files only when run as ls -l (long format), as a "plus" sign after the standard Unix access rights.

Examples

Command	Action and When to Use
getfacl "$DIR"	List access rights on $DIR. Use this first to see current ACL settings before making changes.
setfacl -Rm user:fr_xy1:rX,default:user:fr_xy1:rX "$DIR"	Grant user "fr_xy1" read-only access to $DIR. Use when collaborators need to read your results but not modify them.
setfacl -R -m user:fr_me0000:rwX,default:user:fr_me0000:rwX "$DIR" setfacl -R -m user:fr_xy1:rwX,default:user:fr_xy1:rwX "$DIR"	Grant your own user "fr_me0000" and "fr_xy1" inheritable ("default") read and write access to $DIR. Use for collaborative work where multiple users write data.
setfacl -Rm group:bw16e001:rX,default:group:bw16e001:rX "$DIR"	Grant group "bw16e001" read-only access to $DIR. Use when an entire group needs read access.
setfacl -Rb "$DIR"	Remove all ACL rights. Standard Unix access rights apply again. Use when you want to reset permissions.

ACL Options

• -R: Recursive - apply to all files and subdirectories
• -m: Modify - add or change ACL entries
• -b: Remove all ACL entries
• user:username:rwX: Set permissions for a specific user (r=read, w=write, X=execute only if already set)
• default:user:username:rwX: Set default ACL that new files will inherit
• group:groupname:rwX: Set permissions for a specific group

Recommendation

Use ws_allocate -G or ws_share first. Only use manual ACLs for complex permission scenarios not covered by the workspace tools.

Regular Unix Permissions

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

Making workspaces readable/writable using standard Unix access rights with chmod is only feasible if you are in a research group and you and your co-workers share a common Unix group.

CRITICAL WARNING:

• NEVER use chmod 777 or a+rwx - this makes your data accessible to everyone on the system
• NEVER use chmod o+rwx or chmod o+w - this allows anyone to modify or delete your files
• Do not make files readable or writable to everyone or to large common groups ("all students")
• Only set group permissions (g+r, g+w) for your specific research group

The examples will assume you want to change the directory in $DIR. If you want to share a workspace, DIR could be set with DIR=$(ws_find my_workspace)

Examples

Command	Action and When to Use
chgrp -R bw16e001 "$DIR" chmod -R g+rX "$DIR"	Set group ownership and grant read access to group "bw16e001". Use when group members need read-only access. Note: Has to be re-done if files are added.
chgrp -R bw16e001 "$DIR" chmod -R g+rswX "$DIR"	Set group ownership and grant read/write access to group. Group will be inherited by new files via sticky bit (s), but rights for the group will have to be re-set with chmod for every new file. Use for simple group collaboration.

Unix Permission Options

• -R: Recursive - apply to all files and subdirectories
• g+rwx: Group permissions
  • g: Group
  • +: Add permissions (- to remove)
  • r: Read permission
  • w: Write permission
  • x: Execute permission
  • X: Execute only where execute is set for user (capital X)
• s: Set group ID on directory, so new files inherit group ownership

Recommendation

For group collaboration, prefer ws_allocate -G groupname over manual Unix permissions, as it handles the setup automatically and correctly.

Delete a Workspace

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
ws_release --delete-data (immediate deletion)	✓				✓

To release a workspace, use:

  $ ws_release myWs

Syntax: ws_release [options] workspace_name

What happens when you release:

• The workspace ID can be reused
• The directory is not accessible anymore
• The data is not deleted immediately - it is kept for a grace period
• The data can be recovered using ws_restore as long as it is not finally deleted
• The real deletion will probably take place during nighttime

Important Notes:

• Data in a released workspace can still account for quota usage
• If the data is limiting you, delete the data before releasing the workspace, or restore it, delete it, and release again
• Recommendation: If you need to free quota immediately, delete files with rm -rf before releasing

Options

Option	Description
-n <name>	Workspace name (alternative to positional argument)
-F <filesystem>	Specify filesystem where the workspace is located
--delete-data	Delete all data immediately. WARNING: Workspace can NOT BE RECOVERED

Immediate Deletion

The --delete-data flag immediately deletes all data:

  $ ws_release --delete-data myWs

Warning: Deleted data from workspaces is permanently lost and cannot be recovered.

When to use:

• Use ws_release (without flag) when you might need to recover data
• Use ws_release --delete-data when you're certain you don't need the data and want to free quota immediately

Restore an Expired Workspace

Works on cluster	bwUC 3.0	BinAC2	Helix	JUSTUS 2	NEMO2
ws_restore	✓	✓	✓	✓	✓

For a certain (system-specific) grace time following workspace expiration, a workspace can be restored.

Syntax: ws_restore [options] workspace_name target_name | -l

Restore Procedure

(1) Display restorable workspaces:

  $ ws_restore -l

This will list all workspaces that can still be recovered. You can use -b or --brief to hide the unavailability date in the list.

(2) Create a new workspace as the target for the restore:

  $ ws_allocate restored 60

(3) Restore the expired workspace:

  $ ws_restore <full_name_of_expired_workspace> restored

Important:

• The expired workspace must be specified using the full name as printed by ws_restore -l (not as printed by ws_list!), including username prefix and timestamp suffix (otherwise it cannot be uniquely identified)
• The target workspace must be given with just its short name as listed by ws_list, without the username prefix
• ws_restore can only work on the same filesystem. Ensure the new workspace is on the same filesystem as the expired workspace. Use -F <filesystem> flag if needed

Example:

  $ ws_restore username-myWs-0 restored

Options

Option	Description
-l, --list	List restorable workspaces. Use this first to see what can be recovered
-b, --brief	Do not show unavailability date in list (used with -l)
-n <name>	Workspace name (alternative to positional argument)
-t <target>	Existing target workspace name (alternative to positional argument)
-F <filesystem>	Specify filesystem where the workspace is located
-u <username>	Username (for restoring other users' workspaces if permitted)

If Workspace Cannot Be Restored

If the workspace is not visible/restorable, it has been permanently deleted and cannot be restored, not even by system administrators.

Helix-specific - Workspace Snapshots:

On Helix, if the workspace can't be restored anymore using ws_restore, you can check the snapshots under:

  /work/.snapshots/<timepoint>/ws/

Important notes about snapshots:

• Snapshots are point-in-time copies of the workspace filesystem
• Changes that happened since the last snapshot was created are lost
• Browse available snapshot timepoints in /work/.snapshots/
• Caution: The Helix team tries to keep the latest snapshots, but they cannot guarantee that snapshots will be available at all times
• Snapshots are a last resort when ws_restore no longer works

How to use snapshots:

  $ ls /work/.snapshots/                    # List available snapshot timepoints
  $ cd /work/.snapshots/2025-11-15_00.00.00/ws/
  $ ls                                      # Find your old workspace directory
  $ cp -r username-myWs-0 /path/to/active/workspace/  # Copy data to active workspace

Contact Helix support if you need assistance with snapshot recovery.

Please remember: Workspaces are intended solely for temporary work data, and there is no backup of data in the workspaces.

Recommendation: Email reminders are sent automatically. You can optionally customize reminder timing with -r option to be notified earlier, giving you time to extend the workspace or backup important data to appropriate permanent storage.

Cluster-Specific Information

Retention periods for expired/released workspaces vary by cluster:

Cluster	Expired Workspace Retention	Released Workspace Retention
bwUniCluster 3.0	30 days	Until next night
Helix	System-specific grace period	System-specific grace period
JUSTUS 2	System-specific grace period	System-specific grace period
BinAC2	System-specific grace period	System-specific grace period
NEMO2	30 days	Until next night

Cluster-Specific Workspace Limits

Different clusters have different workspace policies. Below is an overview of typical settings:

Cluster	Default Lifetime	Max Lifetime	Max Extensions	User Quota	Inode Quota
bwUniCluster 3.0	1 day (typical)	60 days (renewable 3x to 240 days total)	3 times	40 TiB	20 million
JUSTUS 2	7 days	90 days	Unlimited	20 TiB	5 million
Helix	N/A	30 days	10 times	10 TiB	No limit
BinAC2	N/A	30 days	5 times	None	None
NEMO2	30 days	100 days	100 times	5 TiB per workspace	No limit

Note: Check your specific cluster documentation for current quotas, as they may change. Use ws_list -l to see available filesystems and their properties on your cluster.

Checking Workspace Quotas

The command to check workspace quota usage varies by cluster and filesystem:

Lustre-based clusters (bwUniCluster 3.0, JUSTUS 2):

  $ lfs quota -uh $(whoami) /lustre/work    # or appropriate workspace path
  $ lfs quota -uh $(whoami) /pfs/work9      # bwUniCluster 3.0

NEMO2 (Weka filesystem):

  $ nemoquota                                # Shows HOME and workspace quotas
  $ df --si $(ws_find workspace_name)        # Check specific workspace

Helix (IBM Spectrum Scale):

  $ workquotainfo                            # Shows workspace quota info

BinAC2:

• No quota limits enforced on workspaces
• Check available space with df command

General tip: Always check disk usage before large data operations to ensure sufficient space is available.

Register Workspace Links

The ws_register command creates or updates symbolic links to your workspaces in a directory of your choice. This provides a convenient way to access all your workspaces from a single location.

Syntax: ws_register [-h] [--version] [-F FILESYSTEM] directory

Usage:

  $ ws_register ~/workspaces

This will create symbolic links to all your workspaces in the ~/workspaces directory.

Example:

  $ mkdir -p ~/my_workspaces
  $ ws_register ~/my_workspaces
  $ ls -l ~/my_workspaces
  lrwxrwxrwx 1 user group 45 Nov 17 10:30 myWs -> /work/workspace/scratch/user-myWs-0
  lrwxrwxrwx 1 user group 48 Nov 17 10:30 project1 -> /work/workspace/scratch/user-project1-0

Options

Option	Description
directory	Directory in which links shall be created/updated (required positional argument)
-F <filesystem>, --filesystem <filesystem>	Filesystem to search workspaces in. Only create links for workspaces on this filesystem
-h, --help	Show help message
--version	Show program's version number and exit

When to use:

• Recommended if you work with multiple workspaces and want quick access
• Use in your ~/.bashrc or login scripts to automatically update links at login
• Useful for organizing workspaces by project or purpose

Example in login script:

# In ~/.bashrc
if command -v ws_register &> /dev/null; then
    mkdir -p ~/workspaces
    ws_register ~/workspaces 2>/dev/null
fi