First, we will get used to the client tools. On the dCache head node, change into the pnfs directory, where the users are going to store their data:

[user] $ cd /pnfs/<site.de>/data/
[user] $

The mounted Chimera filesystem is not intended for reading or writing actual data with regular file operations via the NFS protocol.

Reading and writing data to and from a dCache instance can be done with a number of protocols. After a standard installation, these protocols are dCap, GSIdCap, and GridFTP. In addition dCache comes with an implementation of the SRM protocol which negotiates the actual data transfer protocol.

We will first try dCap with the dccp command:

[user] $ export PATH=/opt/d-cache/dcap/bin/:$PATH
[user] $ cd /pnfs/<site.de>/data/
[user] $ dccp /bin/sh my-test-file
541096 bytes in 0 seconds

This command succeeds if the user user has the Unix rights to write to the current directory /pnfs/<site.de>/data/.

The dccp command also accepts URLs. We can copy the data back using the dccp command and the dCap protocol but this time describing the location of the file using a URL.

[user] $ dccp dcap://<adminNode>/pnfs/<site.de>/data/my-test-file /tmp/test.tmp
541096 bytes in 0 seconds

However, this command only succeeds if the file is world readable. The following shows how to ensure the file is not world readable and illustrates dccp consequently failing to copy the file.

[user] $ chmod o-r my-test-file
[user] $ dccp dcap://<adminNode>/pnfs/<site.de>/data/my-test-file /tmp/test2.tmp
Command failed!
Server error message for [1]: "Permission denied" (errno 2).
Failed open file in the dCache.
Can't open source file : "Permission denied"
System error: Input/output error

This command did not succeed, because dCap access is unauthenticated and the user is mapped to a non-existent user in order to determine the access rights. However, you should be able to access the file with the NFS mount:

[user] $ dccp my-test-file /tmp/test2.tmp
541096 bytes in 0 seconds

If you have a valid grid proxy with a certificate subject which is properly mapped in the configuration file /opt/d-cache/etc/dcache.kpwd you can also try grid-authenticated access via the GSI-authenticated version of dCap:

[user] $ chgrp <yourVO> my-test-file
[user] $ export LD_LIBRARY_PATH=/opt/d-cache/dcap/lib/:$LD_LIBRARY_PATH
[user] $ dccp gsidcap://<adminNode>:22128/pnfs/<site.de>/data/my-test-file /tmp/test3.tmp
541096 bytes in 0 seconds

Or we let the SRM negotiate the protocol:

[user] $ export PATH=/opt/d-cache/srm/bin/:$PATH
[user] $ srmcp srm://<adminNode>:8443/pnfs/desy.de/data/my-test-file file:////tmp/test4.tmp
configuration file not found, configuring srmcp
created configuration file in ~/.srmconfig/config.xml

If the dCache instance is registered as a storage element in the LCG/EGEE grid and the LCG user interface software is available the file can be accessed via SRM:

[user] $ lcg-cp -v --vo <yourVO> \
srm://<dCacheAdminFQN>/pnfs/<site.de>/data/my-test-file \
file:///tmp/test5.tmp
Source URL: srm://<dCacheAdminFQN>/pnfs/<site.de>/data/my-test-file
File size: 541096
Source URL for copy: gsiftp://<dCacheAdminFQN>:2811//pnfs/site.de/data/my-test-file
Destination URL: file:///tmp/test5.tmp
# streams: 1
Transfer took 770 ms

and it can be deleted with the help of the SRM interface:

[user] $ srm-advisory-delete srm://<dCacheAdminFQN>:8443/pnfs/<site.de>/data/my-test-file
 srmcp error :  advisoryDelete(User [name=...],pnfs/<site.de>/data/my-test-file)
Error user User [name=...] has no permission to delete 000100000000000000BAF0C0

This works only if the grid certificate subject is mapped to a user which has permissions to delete the file:

[user] $ chown <yourVO>001 my-test-file
[user] $ srm-advisory-delete srm://<dCacheAdminFQN>:8443/pnfs/<site.de>/data/my-test-file

If the grid functionality is not required the file can be deleted with the NFS mount of the pnfs filesystem:

[user] $ rm my-test-file