M Janczyk: M Janczyk moved page Workspaces/Advanced Features/Sharing to NEMO2/Workspaces/Advanced Features/Sharing

2026-03-02T19:39:29Z

M Janczyk moved page Workspaces/Advanced Features/Sharing to NEMO2/Workspaces/Advanced Features/Sharing

← Older revision	Revision as of 21:39, 2 March 2026
(No difference)

M Janczyk: /* Group Workspaces */

2025-12-02T15:26:46Z

Group Workspaces

← Older revision		Revision as of 17:26, 2 December 2025
Line 68:		Line 68:
	* Use <tt>-G</tt> for collaborative work where everyone writes data		* Use <tt>-G</tt> for collaborative work where everyone writes data
	* Set <tt>groupname</tt> in <tt>~/.ws_user.conf</tt> if you always work with the same group		* Set <tt>groupname</tt> in <tt>~/.ws_user.conf</tt> if you always work with the same group

	See also: [[Workspaces/Groups\|Work with Groups]] guide for more details.

	== Sharing with ws_share ==		== Sharing with ws_share ==

M Janczyk: Created page with "= 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 r..."

2025-12-02T13:32:42Z

Created page with "= Cooperative Usage (Group Workspaces and Sharing) = When working in teams, workspaces can be shared in multiple ways. <div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;"> '''WARNING: NEVER use chmod 777 or a+rwx on workspaces!''' Do '''NOT''' make your workspace readable or writable by everyone (<tt>chmod 777</tt>, <tt>chmod a+rwx</tt>, or <tt>chmod o+rwx</tt>). This is a severe security risk: * Anyone on the system can r..."

New page

= Cooperative Usage (Group Workspaces and Sharing) =

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

<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;">
'''WARNING: NEVER use chmod 777 or a+rwx on workspaces!'''

Do '''NOT''' make your workspace readable or writable by everyone (<tt>chmod 777</tt>, <tt>chmod a+rwx</tt>, or <tt>chmod o+rwx</tt>). 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 <tt>-g</tt>/<tt>-G</tt> flags, <tt>ws_share</tt>, or group-based permissions instead.
</div>

'''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 <tt>-g</tt> and <tt>-G</tt> flags are most widely supported.

== Group Workspaces ==

{| class="wikitable"
|-
!style="width:40%" | Works on cluster
!style="width:10%" | bwUC 3.0
!style="width:10%" | BinAC2
!style="width:10%" | Helix
!style="width:10%" | JUSTUS 2
!style="width:10%" | NEMO2
|-
|<tt>-g</tt> option (group-readable)
|style="text-align:center;" |
|style="text-align:center;" |
|style="text-align:center;" |
|style="text-align:center;" |
|style="background-color:#90EE90; text-align:center;" | ✓
|-
|<tt>-G</tt> option (group-writable)
|style="text-align:center;" |
|style="text-align:center;" |
|style="text-align:center;" |
|style="text-align:center;" |
|style="background-color:#90EE90; text-align:center;" | ✓
|}

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

$ ws_allocate -g myWs 30

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

$ ws_allocate -G projectgroup myWs 30

The group can be specified in the <tt>~/.ws_user.conf</tt> file as well. See [[Workspaces/Advanced_Features/Reminders|Reminders & Configuration]].

'''Important:''' Group members can extend group-writable workspaces (created with <tt>-G</tt>) 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 <tt>-g</tt> when team members only need to read your results
* Use <tt>-G</tt> for collaborative work where everyone writes data
* Set <tt>groupname</tt> in <tt>~/.ws_user.conf</tt> if you always work with the same group

See also: [[Workspaces/Groups|Work with Groups]] guide for more details.

== Sharing with ws_share ==

{| class="wikitable"
|-
!style="width:40%" | Works on cluster
!style="width:10%" | bwUC 3.0
!style="width:10%" | BinAC2
!style="width:10%" | Helix
!style="width:10%" | JUSTUS 2
!style="width:10%" | NEMO2
|-
|<tt>ws_share</tt> command (ACL-based)
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
|style="background-color:#90EE90; text-align:center;" | ✓
|}

With <tt>ws_share</tt> 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 <tt>ws_share</tt> doesn't work on your cluster, use manual ACL commands (<tt>setfacl</tt>) 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 ===

* <tt>-F <filesystem></tt>, <tt>--filesystem</tt>: Specify the workspace filesystem
* <tt>-h</tt>, <tt>--help</tt>: Show help message

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

== ACLs: Access Control Lists ==

{| class="wikitable"
|-
!style="width:40%" | Works on cluster
!style="width:10%" | bwUC 3.0
!style="width:10%" | BinAC2
!style="width:10%" | Helix
!style="width:10%" | JUSTUS 2
!style="width:10%" | NEMO2
|-
|<tt>setfacl</tt>/<tt>getfacl</tt> (ACLs)
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
|style="background-color:#90EE90; text-align:center;" | ✓
|}

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 <tt>ls -l</tt> (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, <tt>user:</tt> and <tt>group:</tt> are <tt>setfacl</tt> keywords. Replace <tt>username</tt> with the actual user login name (e.g., <tt>alice</tt>, <tt>jdoe</tt>) and <tt>groupname</tt> with the actual Unix group name (e.g., <tt>bw11a000</tt>).

'''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 ===

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

'''Important:''' Always use the <tt>default:</tt> prefix to ensure new files get the correct permissions automatically.

=== Recommendation ===

'''Always prefer <tt>ws_allocate -G</tt> or <tt>ws_share</tt> 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 <tt>-G</tt> or <tt>ws_share</tt>

== Regular Unix Permissions ==

{| class="wikitable"
|-
!style="width:40%" | Works on cluster
!style="width:10%" | bwUC 3.0
!style="width:10%" | BinAC2
!style="width:10%" | Helix
!style="width:10%" | JUSTUS 2
!style="width:10%" | NEMO2
|-
|<tt>chmod</tt>/<tt>chgrp</tt> (Unix permissions)
|style="background-color:#90EE90; text-align:center;" | ✓
|style="background-color:#90EE90; text-align:center;" | ✓
|style="background-color:#90EE90; text-align:center;" | ✓
|style="background-color:#90EE90; text-align:center;" | ✓
|style="background-color:#90EE90; text-align:center;" | ✓
|}

Use standard Unix permissions with <tt>chmod</tt> and <tt>chgrp</tt> 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 (<tt>g+r</tt>, <tt>g+w</tt>) 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 ===

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

'''Important:''' The setgid bit (<tt>g+s</tt>) ensures new files belong to the correct group, but their permissions depend on your <tt>umask</tt>. With the default umask (<tt>0022</tt>), new files will NOT be group-writable automatically. You must either:
* Set <tt>umask 0002</tt> in your shell so new files are group-writable by default, OR
* Manually run <tt>chmod g+w</tt> on new files, OR
* Use ACLs with <tt>default:</tt> entries (which override umask and handle permissions automatically)

=== Recommendation ===

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

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

NEMO2/Workspaces/Advanced Features/Sharing - Revision history

M Janczyk: M Janczyk moved page Workspaces/Advanced Features/Sharing to NEMO2/Workspaces/Advanced Features/Sharing

M Janczyk: /* Group Workspaces */