Warning

This page was translated from the original Japanese version by PLaMo Translate. The Japanese version is authoritative; the English translation may contain inaccuracies.

Using File Storage

PFCP provides a file storage system that can be mounted by Pods for use. It supports ReadWriteMany file storage, allowing concurrent read/write access from multiple Pods within an organization.

Creating PersistentVolumeClaim and Mounting it to Pods

To utilize the file storage, you must create a PersistentVolumeClaim resource to request the necessary storage space, and then mount the dynamically provisioned PersistentVolume from your Pods. Below is an example demonstrating this process.

1. Create a PersistentVolumeClaim by specifying the organization-specific StorageClass. The available StorageClass name is standard-rwx-<organization-name>.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: hello-sample-pvc
   spec:
     accessModes:
     - ReadWriteMany
     resources:
       requests:
         storage: 10Gi
     storageClassName: standard-rwx-<organization-name>
   

   In this example, we are creating a PersistentVolumeClaim requesting 10GiB of file storage. After applying this manifest to Kubernetes, the system will dynamically create a PersistentVolume, and you can verify that the PersistentVolumeClaim status becomes Bound as follows:

   $ kubectl -n org-<organization-name> get pvc
   NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               VOLUMEATTRIBUTESCLASS   AGE
   hello-sample-pvc   Bound    pvc-c5bb8161-f8f3-4b2d-b001-0aee300b7478   10Gi       RWX            standard-rwx-<organization-name>   <unset>   3d2h
   

2. You can now use this PersistentVolumeClaim by mounting it in your Pods to access file storage.

   apiVersion: v1
   kind: Pod
   metadata:
     name: jupyter-notebook
   spec:
     containers:
     - name: jupyter-notebook
       image: quay.io/jupyter/scipy-notebook:2024-03-14
       volumeMounts:
       - mountPath: "/hello-sample"
         name: hello-sample-pv
     volumes:
     - name: hello-sample-pv
       persistentVolumeClaim:
         claimName: hello-sample-pvc
   

Limitations

All File Operations Are Processed as Access by the nobody User

In PFCP’s file storage system, all operations on files and directories within the volume are processed as performed by the nobody user (UID 65534, GID 65534). This applies uniformly to all Linux users, including the root user (UID 0).

Note

This limitation only applies to file storage systems. It does not exist for block storage.

As an example, below shows a user with the ubuntu account (UID 1000) creating a new file on the volume, though the operation is processed as access by the nobody user. You can verify that the created file has nobody:nogroup as its owner and group (65534:65534).

ubuntu@pv-test:~$ id
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu)
ubuntu@pv-test:~$ ls -al /data-rwx
total 8
drwxrwxrwx 3 nobody nogroup 4096 Nov 10 23:28 .
drwxr-xr-x 1 root   root    4096 Nov 10 23:09 ..
ubuntu@pv-test:~$ touch /data-rwx/testfile
ubuntu@pv-test:~$ ls -al /data-rwx/testfile
-rw-r--r-- 1 nobody nogroup 0 Nov 10 23:39 /data-rwx/testfile

Even when performing update operations on the /data-rwx/testfile file, which has nobody as its owner, the operation is processed as by the nobody user and succeeds without permission errors.

ubuntu@pv-test:~$ ls -al /data-rwx/testfile
-rw-rw-r-- 1 nobody nogroup 0 Nov 10 23:39 /data-rwx/testfile
ubuntu@pv-test:~$ date >/data-rwx/testfile
ubuntu@pv-test:~$ cat /data-rwx/testfile
Mon Nov 10 23:40:20 UTC 2025
ubuntu@pv-test:~$ ls -al /data-rwx/testfile
-rw-rw-r-- 1 nobody nogroup 29 Nov 10 23:40 /data-rwx/testfile

However, due to this limitation, certain operations on file storage are unavailable, including chown/chgrp commands to modify file owners/groups, and the Pod securityContext fsGroup feature that changes the volume’s group during Pod execution.

chown/chgrp: Results in Operation not permitted errors

When attempting to execute chown/chgrp commands to modify file owners/groups on the volume, an Operation not permitted error occurs and the operation fails as shown below.

root@pv-test:~# id
uid=0(root) gid=0(root) groups=0(root)
root@pv-test:~# chown root /data-rwx/testfile
chown: changing ownership of '/data-rwx/testfile': Operation not permitted
root@pv-test:~# chgrp root /data-rwx/testfile
chgrp: changing group of '/data-rwx/testfile': Operation not permitted

The same error occurs when executing kubectl cp or tar/rsync commands. This is because these commands internally modify file/directory owners. You can avoid errors by using options that prevent owner/group changes with each command.

• kubectl cp: Use the --no-preserve option
• tar: Use the --no-same-owner option
• rsync: Use the --no-owner option

Pod securityContext fsGroup: Configuration is ignored and Pod runs as configured

The Pod SecurityContext fsGroup feature, which allows changing the volume’s group during Pod execution, is ignored for file storage volumes and the Pod will run as configured.

References

• Persistent Volumes | Kubernetes