Problem uploading datasets with PyBIS API after migration (20.10.3 ---> 20.10.12.5)

Installation & maintenance
1

Hi all,
I have an openbis instance that we recently migrated from 20.10.3 to 20.10.12.5 where most things went smoothly.
However, uploading datasets with files from PyBIS (v 1.37.4) has stopped working due to some internal ATOMIC_MOVE that fails moving the file from session-workspace to a mounted NFS data share.

Here’s the error message:

2026-10-01 12:04:08,151 INFO  \[qtp1377456236-45\] OPERATION.DataSetRegistrationTransaction - Start registration
2026-10-01 12:04:08,156 INFO  \[qtp1377456236-45\] OPERATION.AbstractOmniscientTopLevelDataSetRegistrator - Start processing
2026-10-01 12:04:08,447 INFO  \[qtp1377456236-45\] OPERATION.AbstractTransactionalCommand - Moving file '/data/openbis/session-workspace/user-XXXXTOKEN/6210282c-e527-46d4-a598-fab957c9e9cb/base.yaml' to '/data/openbis/store/4/staging/20261001120408183-1371880/base.yaml'
2026-10-01 12:04:08,449 ERROR \[Monitoring Proxy-T1::qtp1377456236-45::remote file operations\] OPERATION.IFileOperations - Java 7 ATOMIC_MOVE failed from '/data/openbis/session-workspace/user-XXXXTOKEN/6210282c-e527-46d4-a598-fab957c9e9cb/base.yaml' to '/data/openbis/store/4/staging/20261001120408183-1371880/base.yaml'
java.nio.file.AtomicMoveNotSupportedException: /data/openbis/session-workspace/user-XXXXTOKEN/6210282c-e527-46d4-a598-fab957c9e9cb/base.yaml -> /data/openbis/store/4/staging/20261001120408183-1371880/base.yaml: Invalid cross-device link
at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:415)
at java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:267)
at java.base/java.nio.file.Files.move(Files.java:1422)
at ch.systemsx.cisd.common.filesystem.FileOperations.rename(FileOperations.java:175)
at ch.systemsx.cisd.common.filesystem.FileOperations.move(FileOperations.java:467)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at ch.systemsx.cisd.common.concurrent.MonitoringProxy$DelegatingInvocationHandler.invoke(MonitoringProxy.java:153)
at ch.systemsx.cisd.common.concurrent.MonitoringProxy$MonitoringInvocationHandler$2.call(MonitoringProxy.java:347)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
2026-10-01 12:04:08,450 ERROR \[qtp1377456236-45\] OPERATION.IFileOperations - Call to method 'IFileOperations.move(File,File)'\[remote file operations\]: exception: Moving '/data/openbis/session-workspace/user-XXXSESSIONTOKEN/base.yaml' into directory '/data/openbis/store/4/staging/20261001120408183-1371880/base.yaml' failed. \[IOExceptionUnchecked\].

We also have a generic dropbox that ingests data directly into one of the mounted NFS shares and it works without any problems.

Uploading datasets using the GUI in ELN also works fine.
It’s only the PyBIS uploads that fails like this.

Would be happy for some inputs!

Best,
Filip

2

Hi again, I solved the problem.
It turned out to be misconfigured symbolic links where session-workspace folder being in /data/openbis share and staging folder in a different share:
Creating a symbolic link in /data/openbis share to the one defined in dss service.properties (in this case share 4) solved the problem:

  1. Log in to the openbis-app docker container as root
  2. If it doesn’t already exist, create session-workspace folder in destination share
mkdir -m 770 /mnt/data4/session-workspace
chown openbis:openbis /mnt/data4/session-workspace
  1. Standing in /data/openbis folder, create a symbolic link between it and the destination share
ln -s /mnt/data4/session-workspace session-workspace
  1. Now you should have a symnolic link in /data/openbis folder to the destination share
ls -la 
lrwxrwxrwx  1 openbis openbis    28 Oct  1 19:56 session-workspace -> /mnt/data4/session-workspace

In this way, the incoming files from PyBIS sessions land in the same share as they are destined to, and openbis internal ATOMIC_MOVE function will work again.