Hello, here is this month's iRODS news and developments!

Click here to read this email on the web.

Exited to see better password hashing being worked on (see 8744 and notes below).

Along with session tokens (8727), this is a big step forward for iRODS security.

iRODSNews

Mastodon Toots

• iRODS Development Update: November 2025

  [https://irods.org/2025/11/irods-development-update-](https://irods.org/2025/11/irods-development-update-)
  november-2025/

  #irods
  #cplusplus
  #globus
  #java #s3
  #duckdb
  #ducklake
  #sc25

  Card: iRODS - iRODS S3 API v0.5.0 is released!

  This release separates bucket mapping and user mapping from the main
  configuration file through use of a new plugin architecture. Administrators
  can now adjust mappings in real time without needing to restart the S3 API
  server.

  https://github.com/irods/irods_client_s3_api/releases/tag/0.5.0

  #irods
  #cplusplus
  #s3

  Card: Release 0.5.0 · irods/irods_client_s3_api
  Description: ImportantThis version requires modification of the S3 API server's configuration file. This release separates bucket mapping and user mapping from the main configuration file through use of a new ... - iRODS Web GUI Metalnx v3.1.1 is released!

  This release fixes the ability to preview PDFs and upgrades Apache Tomcat to 9.0.111.

  [https://github.com/irods-contrib/metalnx-](https://github.com/irods-contrib/metalnx-)
  web/releases/tag/3.1.1

  #irods
  #java
  #tomcat

  Card: Release 3.1.1 · irods-contrib/metalnx-web
  Description: This release fixes the ability to preview PDFs and upgrades Apache Tomcat to 9.0.111. - iRODS Globus Connector v5.0.1 is released!

  https://github.com/irods/irods_client_globus_connector/releases/tag/5.0.1

  #irods
  #globus

  Card: Release 5.0.1 · irods/irods_client_globus_connector
  Description: The iRODS Globus Connector. Contribute to irods/irods_client_globus_connector development by creating an account on GitHub.

GitHub Activity

Main Repository (irods/irods)

Open Issues – irods/irods

• physical quotas are calculated based on original data_owner_name

  State: open
  Labels: bug
  Description: ## Bug Report

iRODS Version, OS and Version

5.0.2 (and all older versions)

What did you try to do?

confirm that a data object with multi-ownership is counted against both owners.

Expected behavior

• one data object, two owners visible via ils -A file.txt
• quotas for that data object should be totaled for every replica/resource, and both owners

Observed Behavior (including steps to reproduce, if applicable)

• only the original data_owner_name is considered

• Release activities for 5.1.0

  State: open
  Labels: documentation
  Description: - [ ] Bump server version -
  Bump icommands version -
  Release notes - Make user_password_storage_mode a grid configuration

  State: open
  Labels: enhancement
  Description:
  igroupadmin mkuser (with a password provided), and iadmin moduser is
  currently a configuration in server_config.json. > > My question is
  whether this ought to be a grid configuration instead. I think the main
  reason it's not right now is because we are planning to remove this
  configuration in iRODS 7. Thinking on it some more, I'm not sure that's a
  good enough reason to not make it a grid configuration in the catalog.
  Originally posted by @alanking in
  #8697 - Prevent iadmin moduser's remove_password from self-clearing password

  State: open
  Labels: enhancement
  Description: ### New Feature / Functionality

This work was broken off from #2899.

The user executing iadmin moduser should not be allowed to remove its own password. GeneralAdmin API should be updated to check for this situation. It should also not be possible to clear a user's password if it is the user for the service account running an iRODS server.

• Enable session token usage in pam_password

  State: open
  Labels: enhancement
  Description: ### New Feature / Functionality

Session tokens are being added in #8697. These could be used in place of time-limited legacy passwords in R_USER_PASSWORD. We can introduce a configuration which allows for switching to session tokens for pam_password authentication. Note: This might have to also include a configuration on the client side, which could get messy.

• Add ARGON2 algorithm for password hashing

  State: open
  Labels: enhancement
  Description: ### New Feature / Functionality

Issue 8697 adds a new authentication scheme which uses scrypt to hash user passwords for storage. We should also support ARGON2 as this appears to be the current industry standard.

For more information about ARGON2 in OpenSSL, see: https://docs.openssl.org/3.2/man7/EVP_KDF-ARGON2

Note: ARGON2 is only available starting in OpenSSL 3.2. Here are the OpenSSL versions on our supported platforms:

This means, unfortunately, that most of our supported platforms will not have access to this. We can use the OPENSSL_VERSION macros to determine whether to build it in or not: https://docs.openssl.org/3.0/man3/OpenSSL_version

• Consider extending logger to support client-side environments

  State: open
  Labels: enhancement
  Description:
  For clients, the logger doesn't do anything. Let's consider extending the
  logger's functionality to account for client-side environments. - Remove conditional includes added by #8740

  State: open
  Labels: deprecation / removal
  Description:
  compatibility. These should be removed for 6.0 - execCmd.h (in lib/api) #includes rodsConnect.h (in server/core)

  State: open
  Labels: bug
  Description:
  lib is #include-ing stuff in server. In file included from /__w/irods/irods/lib/core/include/irods/rcGlobalExtern.h:9: In file included from /__w/irods/irods/lib/core/include/irods/msParam.h:8: /__w/irods/irods/lib/api/include/irods/execCmd.h:4:10: fatal error: 'irods/rodsConnect.h' file not found #include "irods/rodsConnect.h" ^~~~~~~~~~~~~~~~~~~~~ 1 error generated.
  https://github.com/irods/irods/blob/330799c976fbbd51ec399343f14e03ca09858b25/lib/api/include/irods/execCmd.h#L4
  execCmd.h doesn't actually use anything from rodsConnect.h, so the
  #include can be removed. However, we should keep it in for 5.x as a
  conditional include via __has_include, as #includers of execCmd.h may
  expect definitions from rodsConnect.h to be available. This applies to
  another area as well:
  https://github.com/irods/irods/blob/330799c976fbbd51ec399343f14e03ca09858b25/lib/api/include/irods/chkNVPathPerm.h#L5 - Remove interactive mode for iadmin and igrouadmin

  State: open
  Labels: deprecation / removal
  Description: ## Removal

Deprecated here: https://github.com/irods/irods/issues/8738

• Deprecate interactive mode for iadmin and igroupadmin

  State: open
  Labels: deprecation / removal
  Description: ## Deprecation

Add a printout like we did for imeta: https://github.com/irods/irods_client_icommands/commit/811d922c5c061ef680f60f6e6d1b57449349d8bd

printf("NOTE: Interactive mode is deprecated and will be removed in an upcoming release.\n");

And a note in the help text for each.

• Add debug mode output capabilities

  State: open
  Labels: enhancement, testing
  Description:
  debug logic that produces various information in a well-defined location on
  disk or even in the database. Our tests can then assert things based on that
  info. > > > > The debug logic would only exist in debug builds. > > >

  Many projects augment the code in that way, so perhaps this is a good
  opportunity to experiment with that - if there's something you feel would be
  worth it. Originally posted by @korydraughn in
  #8732

• Consider adding additional hash strategies

  State: open
  Labels: enhancement
  Description:
  sha224 (openssl) - sha384 (openssl) - sha3-224 (openssl) - sha3-256
  (openssl) - sha3-384 (openssl) - sha3-512 (openssl) - blake2s256 (openssl) -
  blake2b512 (openssl) - ripemd160 (openssl) - crc32 (zlib or xz/lzma or
  self-implemented) - crc32c (self-implemented) - non-nvme crc64 (xz/lzma or
  self-implemented, should be trivial) - xxhash32 - xxhash64 - xxhash3-64 -
  xxhash3-128 Some resources: -
  https://stackoverflow.com/questions/26429360/crc32-vs-crc32c -
  https://reveng.sourceforge.io/crc-catalogue/17plus.htm -
  https://github.com/Cyan4973/xxHash - https://github.com/ekpyron/xxhashct -
  https://create.stephan-brumme.com/xxhash/ -
  https://github.com/redspah/xxhash_cpp - https://github.com/ekpyron/xxhashct

  • https://github.com/Cyan4973/xxHash/issues/496 - https://github.com/chys87/constexpr-xxh3
  • bulkProcAndRegSubfile has redundant checksum verification

  State: open
  Labels: No Labels
  Description:
  verifyChksumLocFile, and then again immediately after:
  https://github.com/irods/irods/blob/8fc618789753f38d59db40cc87276e89aecbb6d4/server/api/src/rsBulkDataObjPut.cpp#L603-L617 - ips does not report clients with names containing spaces

  State: open
  Labels: bug
  Description:
  iRODS 4.3.4 and 5.x. In my efforts to update iRODS support in
  Cyberduck, I updated the client to report a name which is produced by
  the Cyberduck application. This turned out to be the following. Cyberduck/9.3.0.44005 (Windows 10/10.0.19045.0) (amd64) I soon
  learned that ips was no longer reporting connections from Cyberduck.
  However, interactions between Cyberduck and iRODS continued working just
  fine. Turns out that iRODS doesn't handle more complex client names.
  This is because it uses whitespace to delimit information. #### iRODS 5
  https://github.com/irods/irods/blob/8fc618789753f38d59db40cc87276e89aecbb6d4/server/main_server/src/agent_main.cpp#L1137-L1149
  https://github.com/irods/irods/blob/8fc618789753f38d59db40cc87276e89aecbb6d4/server/api/src/rsProcStat.cpp#L34-L49
  #### iRODS 4.3
  https://github.com/irods/irods/blob/2b1fa9a6bbb59eadd896c66a43515d935db68016/server/core/src/procLog.cpp#L95-L103 - NAME_LEN used where CHKSUM_LEN should be used in many places

  State: open
  Labels: bug
  Description:
  should be using CHKSUM_LEN. At the moment these macros are defined to the
  same value, so fixing this would not break API or ABI and would result in no
  functional changes. However, it should still be fixed, both in case we
  decide to change the value of one of these macros (see #8721) and for the
  sake of correctness. - Allow longer passwords for irods authentication

  State: open
  Labels: enhancement
  Description: ### New Feature / Functionality

Issue 8697 is adding a new way of storing passwords and an authentication scheme to use those passwords.

The legacy passwords used by native authentication are limited to 42 characters (among other limitations). See #6913, https://github.com/irods/irods/issues/6911, and https://github.com/irods/irods/issues/7010.. The way things are implemented now, the new passwords are subject to the same length limitation as the existing machinery for setting passwords is being leveraged for the new passwords as well.

We should (carefully) implement things such that this password limitation is lifted. Here is the relevant place to modify: https://github.com/irods/irods/blob/6bc007183bc10ae50f7938da4a2c395e9c6b2ffb/plugins/database/src/db_plugin.cpp#L7078-L7086

Please ensure that buffer sizes in the various APIs and operations are sufficient to hold the larger passwords and that legacy native password behavior does not change.

• Add option to use irods authentication at setup time

  State: open
  Labels: enhancement, setup / deployment
  Description: ### New Feature / Functionality

For iRODS 5.1, the default authentication scheme for the account running the iRODS server will continue to be native. We should provide an option to use the new irods authentication scheme instead so that it doesn't need to be changed after setup later.

• Add irods auth scheme features to user administration library

  State: open
  Labels: enhancement
  Description: ### New Feature / Functionality

Add hashed password updating, removal, etc. to the user administration library.

Related to #8697.

• Add session management features

  State: open
  Labels: enhancement
  Description: ### New Feature / Functionality

As part of #8697, session tokens are being introduced to iRODS. These are very basic. Consider adding the ability to revoke session tokens, "log out" of iRODS, list active sessions, and other things one might expect with a client-server application's sessions.

• Investigate increasing CHKSUM_LEN

  State: open
  Labels: bug, federation, compatibility
  Description:
  https://github.com/irods/irods/blob/b8781c11aef62b61b3ff3e29d17b52bb105fe372/lib/core/include/irods/rodsDef.h#L40
  This small value causes problems for certain hash algorithms. It isn't large
  enough for some sha512 checksums, for example (see #8704). However, given
  its use in other areas, we must use care when changing this value, as it may
  impact federation and/or client/plugin compatibility. packstruct:
  https://github.com/irods/irods/blob/b8781c11aef62b61b3ff3e29d17b52bb105fe372/lib/core/include/irods/rodsPackTable.h#L36
  rule engine cache:
  https://github.com/irods/irods/blob/b8781c11aef62b61b3ff3e29d17b52bb105fe372/plugins/rule_engines/irods_rule_language/include/irods/private/re/configuration.hpp#L67
  Worth noting, the database column is varchar(1000):
  https://github.com/irods/irods/blob/b8781c11aef62b61b3ff3e29d17b52bb105fe372/plugins/database/src/icatSysTables.sql.pp.in#L79C492-L79C519 - clang-tidy: consider demoting misc-const-correctness to a warning

  State: open
  Labels: build / tools
  Description:
  shouldn't be an error. Consider the following pattern: c++ irods::error ret = do_thing(some_variable); if (!ret.ok()) { THROW(ret.code(), ret.result()); } return some_variable; I would be against making ret
const here, as we might want to add another irods::error returning call
  before the return statement. - Remove isPathSymlink

  State: open
  Labels: deprecation / removal
  Description: isPathSymlink is deprecated in #8711 (PR: #8716). Let's remove it in 6.0. - Avoid "could not create PID file" at iRODS service start

  State: open
  Labels: enhancement, consortium-member
  Description: ### New Feature / Functionality

Minor enhancement request pertaining to packaging/irods.service.template for iRODS 5.0.2

The iRODS daemon needs a directory in /var/run to store its PID file.
When the existing template is installed as-is in conjunction with Ubuntu24, then an attempt to start the iRODS service using systemctl fails and results in a syslog message:
irodsServer[1439]: Error: could not create PID file [/var/run/irods/irods-server.pid].

Adding the following entry in the file packaging/irods.service.template ensures that a directory /var/run/irods is created for the daemon process, with proper access rights. Indeed this appears to resolve the issue.

[service]
RuntimeDirectory=irods

Above entry has been suggested by serverfault.

• Remove base64.h

  State: open
  Labels: deprecation / removal
  Description:
  6.0. - Many of our exported symbol names are too generic

  State: open
  Labels: refactor, compatibility
  Description:
  name a few: - nop - free_const - new_bucket - listAppend -
  is_empty_string - sslStart - region_free - getFile - putSeg -
  isPath - getFileSize - parseUserName - getLine - checkDateFormat -
  isInteger - getErrno - printError - convertDateFormat -
  keyValFromString - seedRandom - startsWith - myWrite -
  get_canonical_name - ProcessType - isLoopbackAddress - setAuthInfo -
  setUserInfo - and many, many, many more. These names are likely to
  collide with other projects and can make developing with iRODS difficult. It
  can additionally cause issues at runtime (as we have previously seen with
  our base64 functions). - Many of our public macro names are too generic

  State: open
  Labels: refactor, compatibility
  Description:
  generic. Just to name a few: - MAX_NAME_LEN - NO_THREADING -
  PUBLIC_USER_NAME - ANONYMOUS_USER - TAR_OVERHEAD - POLICY_OFF -
  NEW_ERROR - LOG_DEBUG - STDOUT_FILE_NAME - PASSWORD - ERROR -
  SUCCESS - THROW - and many, many, many more. These names are likely
  to collide with other projects and can make developing with iRODS difficult.
  There's a few different ways we can deal with these, and it will vary on a
  case-by-case basis. - Move into a namespace and turned into a consteval or
  costexpr declaration - Removal - Renaming (probably to something like
  IRODS_<ORIGNAME>) - Undefine when done - sha512 hasher seems to be broken

  State: open
  Labels: bug
  Description:
  SHA512 and then attempting to use ichksum either results in
  CAT_SQL_ERR or a garbage value for the checksum. I even got it to give me
  a demangled symbol name as the hash value once. - Add new built-in authentication scheme

  State: open
  Labels: enhancement, documentation
  Description:
  iRODS server uses a built-in authentication scheme referred to as
  "native" authentication. It is heavily tied to MD5 hashing which is not
  compliant with FIPS, an aspiration of iRODS: #3403. In order to maintain
  backwards compatibility, we have decided not to change this for native
  authentication. Instead, we will introduce a new built-in authentication
  scheme as an alternative and, eventually, a replacement for native
  authentication. The proposed name for the new authentication scheme is
  "irods". #### Passwords "irods" authentication will use passwords
  stored in the iRODS catalog just like native authentication. The
  passwords will be stored in a new table in the catalog called
  R_USER_CREDENTIALS. The passwords will be hashed with a
  randomly-generated salt using a secure algorithm. #### Session tokens
  iRODS will gain the ability to generate a "session token" - a token with
  an expiration time which can be used to authenticate connections with
  the iRODS server. Session tokens will be stored in the iRODS catalog in
  the currently-unused R_USER_SESSION_KEY table. Session tokens expire
  based on a grid configuration defaulting to 1209600 seconds (2 weeks)
  from the time the session token is created. rodsadmin users will have
  the ability to request a token which does not expire for use with
  running services and even the iRODS service account. #### "irods"
  authentication plugin The new authentication scheme will be implemented
  through a new authentication plugin. Here is the basic set of steps: 1.
  Client presents a password to authenticate the user's connection. 2. The
  server checks the password against the stored hashes in the catalog. 3.
  On success, a session token is generated and used to authenticate the
  client. 4. The session token is returned to the client. This should be
  used to authenticate the client for the duration of the session token's
  lifetime. The iRODS client library will provide a means of storing
  session tokens in a local file called .irods_secrets under the usual
  .irods directory, much like an .irodsA file for native
  authentication. Session tokens should be treated like passwords and
  should not be shared. iinit will instruct the "irods" authentication
  client-side plugin to record session tokens in this file for users of
  the new scheme. - root resource querying

  State: open
  Labels: enhancement, consortium-member
  Description: ### New Feature / Functionality

I am not sure if this has been asked before, but I couldn't find it. Suppose you have a resource hierarchy with child resources like for example below:
hot:passthru
└── somename:unixfilesystem
cold:passthru
└── myarchive:s3

The user will use the roots of the resource hierarchy to comunicate with irods. E.g. iget -R hot /zone/home/user/myfile.txt. The other operations like iput,itrim,irepl etc are also based on the root resource name(or replica number). However, if you query irods, you will get either the leaf resourcename(somename), or the entire hierarchy(hot;somename), but never just the root(hot). If you are creating scripts you can always automate a way to get the root resource, but for generic usage, would it make sense to have this natively in the irods genquery(2) even though this is not a database column?

So e.g. adding next to DATA_RESC_NAME and DATA_RESC_HIER also a DATA_RESC_ROOT_NAME?

One might even argue that if you are unfamiliar with how irods works internally, that you would expect to get hot as a result for DATA_RESC_NAME, but switching that feels like a big step.

Closed Issues – irods/irods

• Closed on 2025-11-05:

  Remove lib/api/doxygen-api.config - Closed on 2025-11-11:

  svrReconnect declared but never defined - Closed on 2025-11-11:

  getParentPathlen is declared but never defined - Closed on 2025-11-11:

  irodsCloseSock is declared but never defined - Closed on 2025-11-11:

  isPathSymlink should've been deprecated ages ago - Closed on 2025-11-11:

  addIntArray is declared but never defined - Closed on 2025-11-11:

  resolveStatForStructFileOpr is declared but never defined - Closed on 2025-11-11:

  untarBuf and tarToBuf are declared but never defined - Closed on 2025-11-11:

  getValByInx is declared but never defined - Closed on 2025-11-03:

  Quota calculations are incorrect when two quotas are active - Closed on 2025-11-14:

  consumer server issue on 4.3.4 - Closed on 2025-10-22:

  Multiple group quotas on same resource are applied improperly - Closed on 2025-11-05:

  imiscsvrinfo segfaults when talking to a server earlier than 4.3.4 - Closed on 2025-11-06:

  Implement HTTP API's packing instructions compatibility approach - Closed on 2025-11-14:

  Add ability to read the checksum directly from object store - Closed on 2025-10-27:

  ilocate/igetwild and iRODS session - Closed on 2025-10-24:

  Create C++ template project for new authentication plugin framework plugins - Closed on 2025-10-27:

  iRODS authentication file different between Operating Systems - Closed on 2025-11-13:

  Quotas are not being calculated and checked properly - Closed on 2025-10-27:

  use of obfGetPw() fails when length is close to MAX_PASSWORD_LEN - Closed on 2025-10-27:

  GSI authentication: certificates size may overflow iRODS message size - Closed on 2025-10-27:

  change password obfuscation code to use SHA1 - no more MD5 - Closed on 2025-10-27:

  Binary Registry for Plugins and other Server Binaries

Python iRODS Client (irods/python-irodsclient)

Open Issues – irods/python-irodsclient

• Figure out why test spuriously fails

  State: open Labels: bug, testing Description:irods/test/data_obj_test.py py def test_access_time__issue_700(self): if self.sess.server_version < (5,): self.skipTest("iRODS servers < 5.0.0 do not provide an access_time attribute for data objects.") data_path= iRODSPath(self.coll.path, unique_name(my_function_name(), datetime.now()) ) with self.sess.data_objects.open(data_path,"w") as f: f.write(b'_') with self.sess.data_objects.open(data_path,"r") as f: f.read() data = self.sess.data_objects.get(data_path) self.assertGreaterEqual(data.access_time, data.modify_time) The failure is as follows ``` ====================================================================== FAIL [0.142s]: test_access_time__issue_700 (data_obj_test.TestDataObjOps)

  Traceback (most recent call last): File
  "/prc.rw/irods/test/data_obj_test.py", line 3317, in
  test_access_time__issue_700 self.assertGreaterEqual(data.access_time,
  data.modify_time) AssertionError: datetime.datetime(2025, 11, 14, 16, 32,
  28, tzinfo=datetime.timezone.utc) not greater than or equal to
  datetime.datetime(2025, 11, 14, 16, 32, 29, tzinfo=datetime.timezone.utc)

  My circumstances. At the worst, the two timestamps should be equal. It's as if the server fails to update the read timestamp under some kind of race condition. We should investigate.

• Use pg_isready where possible

  State: open
  Labels: testing
  Description:
  https://github.com/irods/python-irodsclient/pull/772#discussion_r2429459239_ - Use unattended install for iRODS provider nodes

  State: open
  Labels: testing, setup / deployment
  Description:
  https://github.com/irods/python-irodsclient/pull/772#discussion_r2427109762 - Remove the docker_build directory and its contents

  State: open
  Labels: deprecation / removal
  Description:
  obsolete. - Include pam_interactive in automatic tests run in Github

  State: open
  Labels: testing
  Description:
  pam_interactive. Related: #697, #762 - Update peripheral pam_password tests and support functions for auth framework

  State: open
  Labels: enhancement
  Description:
  well as the Python client suite tests in irods/test/login_auth_test*.py,
  need to be adapted to work under the new auth framework before the legacy
  code on which they're dependent is removed from the server.

Closed Issues – irods/python-irodsclient

NFSRODS (irods/irods_client_nfsrods)

Open Issues – irods/irods_client_nfsrods

• Input/output error with nfsrods 2.3.1

  State: open
  Labels: bug
  Description:
  network. When reading a file on the client mounting the network share, i
  got the following : $ cat /mnt/SHARE/FBIOMEROv2/Figure5/Figure5B/ome.xml [...] </MapAnnotation> <MapAnnotation ID="Annotation:1028667460" Namespace="quay"> <Value> <M K="quay_id">img_3b1e79ea-ae88-11f0-8303-fa163ea9274a</M> </Value> </MapAnnotation> <MapAnnotation ID="Annotation:1004525017" Namespace="quay"> <Value/> </MapAnnotation> </Structcat: /mnt/SHARE/FBIOMEROv2/Figure5/Figure5B/ome.xml: Input/output error I got
  the same error copying the file, and i still got it even after restarting
  the NFSrods docker container and / or remounting the mount on the client.
  If i iget the file directly from iRods, the file can be read entirely. It
  is not corrupted. The file is a 169 line long XML file. The nfsrods config
  file : $ cat nfsrods_config/server.json { "nfs_server": { "port": 2049, "irods_mount_point": "/devZone", "user_access_refresh_time_in_milliseconds": 1000, "user_information_refresh_time_in_milliseconds": 1000, "user_type_refresh_time_in_milliseconds": 1000, "user_permissions_refresh_time_in_milliseconds": 1000, "file_information_refresh_time_in_milliseconds": 1000, "object_type_refresh_time_in_milliseconds": 1000, "list_operation_query_results_refresh_time_in_milliseconds": 1000, "using_oracle_database": false }, "irods_client": { "zone": "devZone", "host": "nte-irods-icat", "port": 1247, "default_resource": "nteuserResc", "ssl_negotiation_policy": "CS_NEG_REFUSE", "proxy_admin_account": { "username": "********", "password": "********" } } } $ cat nfsrods_config/exports / *(rw,acl,no_root_squash) The client fstab :
  10.XXX.XXX.XXX:/home /mnt/SHARE nfs noac,lookupcache=none 0 0 EDIT
  : I tested this deeper and i broke down our workflow to the following test
  : - Generate a long file containing random strings, with a random line
  count (while true; do echo $RANDOM >> /mnt/coop/home/FBIOMEROv2/file.txt; done) - ireg -rf the folder containing the file in iRods At this point
  there is no problem in NFSrods, the file can be normally read. The problem
  occur when you run the test again : - Remove the file from the server

  • Generate a long file containing random strings, with a random line count (while true; do echo $RANDOM >> /mnt/coop/home/FBIOMEROv2/file.txt; done)
  • ireg -rf the folder containing the new file in iRods Now the error on NFSrods is not always the same. I got to corrupt some files doing that, but sometimes the file stops before the end without an Input/output error, and sometimes the changes are juste not reflected on NFSrods, the first file appears on the client.

Closed Issues – irods/irods_client_nfsrods

HTTP API Client (irods/irods_client_http_api)

Open Issues – irods/irods_client_http_api

• Adding additional values into the /info endpoint

  State: open
  Labels: enhancement, consortium-member
  Description:
  some additional information to the /info endpoint? Mainly the value of
  /http_server/authentication/basic/timeout_in_seconds. I’m trying to
  implement automatic token refreshes in our Python HTTP API client, and this
  would be really useful. I’m solving an issue where the token expires and the
  API returns a 401 Unauthorized so the client need to reauthenticate. This is
  a bit problematic when uploading files in parallel using 5 workers. I would
  like to implement functionality that controls the session expiration and
  refreshes it on its own, so there wouldn’t be any try except. For that
  reason, I would need the timeout_in_seconds value, so the solution would
  be generic for every configuration. Thanks

Closed Issues – irods/irods_client_http_api

Demo Repository (irods/irods_demo)

Open Issues – irods/irods_demo

• track data transfers in and out

  State: open
  Labels: enhancement
  Description: to be visualized via #123

Closed Issues – irods/irods_demo

• Closed on 2025-11-10:

  upgrade PostgreSQL to v17

YODA (UtrechtUniversity/yoda)

Open Issues – UtrechtUniversity/yoda

• Add option to reserve a DOI

  State: open
  Labels: No Labels
  Description: ### Is there an existing feature request for this? -
  I have searched the existing feature requests

Is your feature request related to a problem? Please describe.

Currently is not possible to reserve a DOI beforehand for a publication. Reserving a DOI allows researchers to cite their dataset in a manuscript or preprint even before the data is publicly available. This ensures that the dataset is properly linked to the publication from the start of the research cycle. Many journals now require authors to include a DOI for the underlying data in their submissions.

Describe the solution you'd like

Ideally, once the dataset has been submitted to the Vault, there should be a button that allows users to reserve a DOI before submitting the dataset for publication. Having a reserved DOI allows authors to meet journal requirements without prematurely publishing the dataset. Once the dataset is approved, it is published and the reserved DOI becomes active.

Describe alternatives you've considered

The current solution is to publish the dataset under embargo in order to generate a DOI. However, this doesn’t fully address the issue, as it pressures researchers to publish the dataset as soon as possible.

Additional Context

We've received this request many times, as it's possible to do this in other repositories, e.g. Zenodo, DANS, 4TU.

Acceptance Criteria

There's a button that allows users to reserve a DOI before submitting the dataset for publication.

• Add warning message for certain combinations of 'Data classification' and 'Data package access'

  State: open
  Labels: No Labels
  Description: ### Is there an existing feature request for this? -
  I have searched the existing feature requests

Is your feature request related to a problem? Please describe.

The current default metadata form has different metadata fields related to the 'openness' of the data package. Two of these, 'Data classification' and 'Data package access' are both mandatory fields that, based on their selected value, can be conflicting. e.g. if 'Data classification: Sensitive' is selected, 'Data package access: Open' should most likely not be selected.

Describe the solution you'd like

An automated warning text when conflicting values for access are selected, see image.
The warning message should appear with the combination of:
Data classification: basic, sensitive or critical
Data package access: open

Describe alternatives you've considered

A popup message has been considered, but this is then only visible to the user, not to the data manager. A text in the form that is also visible for the data manager.

Additional Context

/

Acceptance Criteria

An automated warning text appears when conflicting values for access are selected

• Add a 'Request access' button to the publications landing pages for publications with Restricted access.

  State: open
  Labels: consortium
  Description: ### Is there an existing feature request for this? -
  I have searched the existing feature requests

Is your feature request related to a problem? Please describe.

At the moment, if a publication has a 'Restricted access', readers have to scroll all the way to the bottom of the (publication landing) page to get to a button 'QUESTIONS?' - that will lead to our WUR Library email address (data@wur.nl). This is not the most user friendly and confusing.

Describe the solution you'd like

I would like to propose a similar solution to the one that is already implemented for 'Open access' publications.

Before the Metadata part, a button can be placed (that is the same as the button at the bottom of the page actually ), saying
"Request access?" and then link to the 'help desk' or whoever is responsible for granting access.

Describe alternatives you've considered

Readers can always scroll to the bottom of the page of course. But this feature of having a 'Request access' button on top of the page is much more user friendly and clear than the current alternative.

Additional Context

/

Acceptance Criteria

Once the button is placed it should lead to the right 'authority' for granting access, preferably to the same location/address as the 'Questions?' button at the bottom of the page.

• Export Metadata information to a README.txt(md) file.

  State: open
  Labels: No Labels
  Description: ### Is there an existing feature request for this? -
  I have searched the existing feature requests

Is your feature request related to a problem? Please describe.

To comply with good RDM practices, users are required to fill-in Yoda Metadata form and create a README file. The README file contains more or less the same information as the Metadata form (of course with much more details about metodology, equipments, ... and many other aspects that are not present in the metadata form.) Researchers have to 'double' the work sort of speak.

Describe the solution you'd like

I would like to propose an automatic and simple translation of the yoda-metadata.json file to a README.txt or README.md file for those metadata fields that have been entered in the metadata form. Whenever the metadata form gets updated, the README file gets updated too. In this way, the researches will get an already pre-made 'skeleton' of the README file where they will add the missing information (about equipment, methodology, software,...) , but they will be spared doubling and copy-pasting the information that they already filled-in in the metadata form.

Describe alternatives you've considered

/

Additional Context

/

Acceptance Criteria

The feature should correctly copy the contents of the yoda-metadata.json file (only the metadata fileds that have been filled-in in the Metadata form) into README file and update the README file whenever the metadata form has been altered.

• distinguishable waiting icons for different roles

  State: open
  Labels: consortium
  Description: ### Is there an existing feature request for this? -
  I have searched the existing feature requests

Is your feature request related to a problem? Please describe.

When changing the role of a user in the Yoda group manager the system shows a message stating the role has been updated or that the user already has that role. Before changing the role, it is however impossible to see which role the user has because all 3 roles use the same “torso with clock“ icon.
This makes it impossible to see which role the invited user currently has.
Expected behavior is that we can see in one glance which role the user is (intended) to have.

Describe the solution you'd like

Since there is currently no direct translation between the role in Yoda and in SRAM, in Yoda 2.0 it can currently not distinguish between different roles.
But when the new version of SRAM is implemented in a future 2.x release, the user roles in SRAM and Yoda can be consistently synchronized. Would it be possible to make 3 different waiting icons for the 3 different roles?
As a suggestion Yoda could use the same standard icons but shown with a different color or transparent.

Describe alternatives you've considered

The workaround for now is to change the role to the intended role in Yoda, based on the message (role updated or 'already has this role') the role the user that still has to accept can then be confirmed. But in the future, seeing roles at a glance is important for admins and group managers.

Additional Context

Bug / feature request reported to us by VU during 2.0 acceptance testing

Acceptance Criteria

The feature should allow group managers to see in one glance which role the user is (intended) to have, also when they have not yet accepted the SRAM invitation.

Closed Issues – UtrechtUniversity/yoda

• Closed on 2025-11-12:

  CSV import not working for group updates - Closed on 2025-11-12:

  Deleting a locked file - Closed on 2025-11-12:

  [BUG] Clicking on research folder link occasionally shows a empty upload popup.

If you think someone else would appreciate this newsletter, they can sign up.

If you don't want to get these emails any more, you can unsubscribe here.

One Yak was shaved in the making of this newsletter.