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.
Almost 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
| Works on cluster | bwUC 3.0 | BinAC2 | Helix | JUSTUS 2 | NEMO2 |
|---|---|---|---|---|---|
| ws_allocate -x -u (extend other user's workspace) | ✓ |
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 -G |
| -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 (see the Cluster-Specific Workspace Limits)). 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 Workspaces 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 Workspaces 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. Requires group write access ws_allocate -G:
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:
Important: Some versions of the workspace tools mistakenly interpret a leading comment line in ~/.ws_user.conf as an email address. Make sure the first line does not start with #. Start with a setting like duration: 30; inline end-of-line comments are fine.
duration: 30 # Default workspace lifetime (first line must not start with #) # ~/.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 # 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: bw11a000
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.
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
| 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.
Delete a Workspace
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 immediately
- The directory becomes inaccessible
- The data is not deleted immediately - it is kept for a grace period
- The data can be recovered using ws_restore during the grace period
- Final deletion typically happens during nighttime maintenance
- Important: Released workspace data may still count toward your quota until final deletion occurs
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 (Free Quota Instantly)
| Works on cluster | bwUC 3.0 | BinAC2 | Helix | JUSTUS 2 | NEMO2 |
|---|---|---|---|---|---|
| ws_release --delete-data (immediate deletion) | ✓ | ✓ |
If you need to free quota immediately instead of waiting for the grace period, you have two options:
Option 1: Use --delete-data flag (recommended if available on your cluster):
$ ws_release --delete-data myWs
Availability: Check if this flag is available on your cluster with ws_release -h.
Option 2: Manual deletion before release (works on all clusters):
$ rm -rf -- "$(ws_find myWs)" $ ws_release myWs
Why this is safe:
- -- prevents path from being interpreted as option (even if it starts with -)
- Quotes around $(ws_find myWs) handle paths with spaces safely
- If ws_find fails or returns empty, rm fails with "missing operand" (no deletion occurs)
- Direct and simple - no complex patterns or subshells needed
CRITICAL WARNING: Both methods permanently delete data that cannot be recovered, even by system administrators.
When to use immediate deletion:
- ✓ You're certain you don't need the data anymore
- ✓ You've already backed up important results to permanent storage
- ✓ You're hitting quota limits and need space immediately
- ✗ Don't use if there's any chance you might need the data
- ✗ Don't use if you haven't verified your backup worked
Best practice: Use regular ws_release myWs (without immediate deletion) as your default. Only use immediate deletion when you're absolutely certain and need immediate quota relief.
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 | 30 days |
| 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 | 30 days |
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 | 60 days | 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 | None |
| BinAC2 | N/A | 30 days | 5 times | None | None |
| NEMO2 | 30 days | 100 days | 100 times | 5 TiB per workspace | None |
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
his will create symbolic links to all your workspaces in the ~/workspaces directory. The command creates subdirectories for each filesystem (e.g., classic/) and places workspace links inside them.
Example:
$ mkdir -p ~/my_workspaces $ ws_register ~/my_workspaces $ ls -l ~/my_workspaces/scratch/ lrwxrwxrwx 1 user group 45 Nov 17 10:30 user-myWs -> /work/workspace/scratch/user-myWs-0 lrwxrwxrwx 1 user group 48 Nov 17 10:30 user-project1 -> /work/workspace/scratch/user-project1-0
Note: Links use the full workspace names (including username prefix), organized by filesystem subdirectory.
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