NFS Share empty

Hello,

I am somewhat new to docker so this might be a simple answer. I have searched for this and can’t seem to get a definitive answer.

I have set up a NFS share on my Synology. I have also set up a volume through Portainer on my Ubuntu server and successfully connected to it.

I have created a test.txt file on the server in the correct folder on my server and it appears on the Synology so I know the connection is working.

I have spun up a test container and attached the Synology volume during the installation. The container has started successfully and is working but the volume in the Synology is empty.

Why is it empty? I have watched many YouTube videos and searched the Docker documentation and just can’t seem to figure out why its empty.

I’m also wondering, since the container is working and the NSF volume is empty, what is the point of attaching the external volume to the container?

And if I did it incorrectly why was there no errors and then where is the data for the container if its not in the NFS share?

I know I read about the volumes contain persistent data but what data would be persistent for the container if the container that is running has not written anything to the external share?

Sorry if this is not making sense, I’m trying to describe it the best I can.

I apologize in advance if this is a simple oversight and I would not post to a forum if I have not come to an end in my search for the answer.

Any insight would be greatly appreciated.

-William

We would need to see how you created the container and know more about your environment in order to help.

The point of a persistent volume is that when you write data into a container’s filesystem, that is only temporary as long as the container exists. And containers are deleted when a new image is used after an upgrade or when you change some parameters. So you would lose data frequently without a volume or bind moutned folder.

If you don1t see the data written to the NFS server, you likely mounted the source folder to a wront one in the container or used a wrong source. Docker can show error message only when it can detect something was wrong. If the mount point or the source is wrong, that is not something it can detect. In case of NFS, it is also possible that you mounted the folder before the NFS server’s fodler was mounted. Not likely when you are duing it manually, but if a process already read the filesystem before mounting the NFS fodler, it could see the original folder before the mount, so even if you see the folder was mounted from the NFS server, it is possible the process still don’t see it.

We can say more only when you share more info. A compose file or docker run command could help a lot depending on how you created the container. Please share also how you installed Docker. Let me share a question template and ignore the info you already shared:


We usually need the following information to understand the issue:

  1. What platform are you using? Windows, Linux or macOS? Which version of the operating systems? In case of Linux, which distribution?

  2. How did you install Docker? Sharing the platform almost answers it, but only almost. Direct links to the followed guide can be useful.

  3. On debian based Linux, the following commands can give us some idea and recognize incorrectly installed Docker:

    docker info
    docker version
    

    Review the output before sharing and remove confidential data if any appears (public IP for example)

    dpkg -l 'docker*' | grep '^ii'
    snap list docker
    

    When you share the outputs, always format your posts according to the following guide: How to format your forum posts

1 Like

Hello and thank you for the reply

I mounted the Synology folder before I created the linkding container so not sure that would be the issue.

I’m using Ubuntu Server 24.04.3 LTS, Release 24.04

Installed Docker with the following:

sudo apt install ca-certificates curl gnupg lsb-release -y
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo   "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \ 
https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" |   sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y 
sudo systemctl enable docker
sudo systemctl start docker   

I installed the container linkding, a bookmark container. (sissbruecker/linkding:latest)
I installed it using portainer with the following relevant settings:

volume mapping:
container: /linkding
volume: my_docker_data  (the volume on my Synology)

Output from Docker info

Client: Docker Engine - Community
 Version:    28.5.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.29.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.40.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 2
 Server Version: 28.5.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: b98a3aace656320842a23f4a392a33f46af97866
 runc version: v1.3.0-0-g4ca628d1
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-87-generic
 Operating System: Ubuntu 24.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.4GiB
 Name: ubuntu
 ID: 62922f4b-9653-442c-b717-7c8b68e175c0
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

Output from Docker version

 Client: Docker Engine - Community
 Version:           28.5.1
 API version:       1.51
 Go version:        go1.24.8
 Git commit:        e180ab8
 Built:             Wed Oct  8 12:17:26 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.5.1
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.8
  Git commit:       f8215cc
  Built:            Wed Oct  8 12:17:26 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.28
  GitCommit:        b98a3aace656320842a23f4a392a33f46af97866
 runc:
  Version:          1.3.0
  GitCommit:        v1.3.0-0-g4ca628d1
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output from dpkg -l ‘docker*’ | grep ‘^ii’

ii  docker-buildx-plugin      0.29.1-1~ubuntu.24.04~noble   amd64        Docker Buildx plugin extends build capabilities with BuildKit.
ii  docker-ce                 5:28.5.1-1~ubuntu.24.04~noble amd64        Docker: the open-source application container engine
ii  docker-ce-cli             5:28.5.1-1~ubuntu.24.04~noble amd64        Docker CLI: the open-source application container engine
ii  docker-ce-rootless-extras 5:28.5.1-1~ubuntu.24.04~noble amd64        Rootless support for Docker.
ii  docker-compose-plugin     2.40.3-1~ubuntu.24.04~noble   amd64        Docker Compose (V2) plugin for the Docker CLI.

No Snap installed

You forgot to share how you created the container. If you created it in Portainer, please share the output you get when you click on inspect in the container details view (make sure to anonymize password, access tokens, public ips or public domain names in the output before posting it here!). Furthermore share the Volume options section in Portainer Volume detail view for the nfs volume.

Did you check the error logs of the container? If you didn’t align the nfs shares owner or group with the process that runs inside a container, it might not be able to write into the remote share.

If you define the NFS connection in a compose file or any way for a specific container, it doesn’t even matter if you mounted the volume. But as @meyay emphesized, we would like to see how you created the container or “a container” reproducing the same issue.

Since we are talking about mounts, if the full output of the inspect is too long, you can share the output of this command:

docker container inspect CONTAINERNAME --format '{{ json .Mounts }}' | (jq 2>/dev/null || python3 -m json.tool)

Change CONTAINERNAME to the actual container name.

Hello,

Here is the requested info :slight_smile:

Output from Inspect in portainer

{
    "AppArmorProfile": "docker-default",
    "Args": [],
    "Config": {
        "AttachStderr": false,
        "AttachStdin": false,
        "AttachStdout": false,
        "Cmd": [
            "./bootstrap.sh"
        ],
        "Domainname": "",
        "Entrypoint": null,
        "Env": [
            "PATH=/etc/linkding/.venv/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "GPG_KEY=redacted",
            "PYTHON_VERSION=3.13.7",
            "PYTHON_SHA256=5462f9099dfd30e238def83c71d91897d8caa5ff6ebc7a50f14d4802cdaaa79a",
            "VIRTUAL_ENV=/etc/linkding/.venv",
            "UWSGI_MAX_FD=4096"
        ],
        "ExposedPorts": {
            "9090/tcp": {}
        },
        "Healthcheck": {
            "Interval": 30000000000,
            "Retries": 3,
            "Test": [
                "CMD-SHELL",
                "curl -f http://localhost:${LD_SERVER_PORT:-9090}/${LD_CONTEXT_PATH}health || exit 1"
            ],
            "Timeout": 1000000000
        },
        "Hostname": "95f144a65861",
        "Image": "sissbruecker/linkding:latest",
        "Labels": {
            "org.opencontainers.image.source": "https://github.com/sissbruecker/linkding"
        },
        "OnBuild": null,
        "OpenStdin": false,
        "StdinOnce": false,
        "Tty": false,
        "User": "",
        "Volumes": {
            "/linkding": {}
        },
        "WorkingDir": "/etc/linkding"
    },
    "Created": "2025-11-02T14:34:40.818104293Z",
    "Driver": "overlay2",
    "ExecIDs": [
        "f1c0c2fd722f672b62126452a8ac2629511466c749a0ffad749e3eb927ca086b",
        "bebdced1ff4589aff6e81b93a1dec2cbd8d23c34f5950265d52eaf9883df3ffe",
        "547f4b90936fb1496e0234632f33fb2fb374e087a576c74daf9273daa10760aa"
    ],
    "GraphDriver": {
        "Data": {
            "ID": "95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548",
            "LowerDir": "/var/lib/docker/overlay2/85bf0913754539107c73852cd7c3bfd0f350070f511c7c6c6e0a3bdc44039d8b-init/diff:/var/lib/docker/overlay2/c4c5bb14707c49cd79b1fdd289ebb43db8c078ad3a3c6f96473b4460ee59a3b6/diff:/var/lib/docker/overlay2/f782c9d05f4a352b421e4bc89ac0f08eb1f1697f7a413c8c140c1caf1a6c04d7/diff:/var/lib/docker/overlay2/5db99c1062e4ee55dc9ba26511bbd7a598f9afec7792e77f909609af0a614948/diff:/var/lib/docker/overlay2/06a484b651c6f1a9ccefde0dfcc632c973b3123d5fad6bfb1066b1a217980290/diff:/var/lib/docker/overlay2/eacf1bd9933fa8f2a45ae0b1ba3396f904a15d09dc4f1ab8f87a57f7baabb618/diff:/var/lib/docker/overlay2/abec78cc54f8340ec9df8a227fb0ba64ab7ccd69879179e2cb7bce9a8c4e0a83/diff:/var/lib/docker/overlay2/2fde49af7100479487d899050659002fb4eac891530517763646396c2be3e78d/diff:/var/lib/docker/overlay2/2981003fc318de389e6295c9f96f7a84d3897acc80aa8f804f8df728f0e25e2b/diff:/var/lib/docker/overlay2/7abbb7c246b817c2a2064dc814f71c01901cc5aea1d2e3fac352fc56d097516e/diff:/var/lib/docker/overlay2/98f89622a4633bf4b4469e460d7b66a09e2d84777f938beddc3f03483daa4947/diff:/var/lib/docker/overlay2/6e02b55e7ac1b94e30af8031f6c1ca386719725be792cabe1d67e67cd542f12e/diff:/var/lib/docker/overlay2/0eda0361208f0709ffd70854a5b1e0bf735d886532234e829fa628b144b9b333/diff",
            "MergedDir": "/var/lib/docker/overlay2/85bf0913754539107c73852cd7c3bfd0f350070f511c7c6c6e0a3bdc44039d8b/merged",
            "UpperDir": "/var/lib/docker/overlay2/85bf0913754539107c73852cd7c3bfd0f350070f511c7c6c6e0a3bdc44039d8b/diff",
            "WorkDir": "/var/lib/docker/overlay2/85bf0913754539107c73852cd7c3bfd0f350070f511c7c6c6e0a3bdc44039d8b/work"
        },
        "Name": "overlay2"
    },
    "HostConfig": {
        "AutoRemove": false,
        "Binds": [
            "my_docker_data:/linkding"
        ],
        "BlkioDeviceReadBps": null,
        "BlkioDeviceReadIOps": null,
        "BlkioDeviceWriteBps": null,
        "BlkioDeviceWriteIOps": null,
        "BlkioWeight": 0,
        "BlkioWeightDevice": null,
        "CapAdd": [
            "AUDIT_WRITE",
            "CHOWN",
            "DAC_OVERRIDE",
            "FOWNER",
            "FSETID",
            "KILL",
            "MKNOD",
            "NET_BIND_SERVICE",
            "NET_RAW",
            "SETFCAP",
            "SETGID",
            "SETPCAP",
            "SETUID",
            "SYS_CHROOT"
        ],
        "CapDrop": [
            "AUDIT_CONTROL",
            "BLOCK_SUSPEND",
            "DAC_READ_SEARCH",
            "IPC_LOCK",
            "IPC_OWNER",
            "LEASE",
            "LINUX_IMMUTABLE",
            "MAC_ADMIN",
            "MAC_OVERRIDE",
            "NET_ADMIN",
            "NET_BROADCAST",
            "SYSLOG",
            "SYS_ADMIN",
            "SYS_BOOT",
            "SYS_MODULE",
            "SYS_NICE",
            "SYS_PACCT",
            "SYS_PTRACE",
            "SYS_RAWIO",
            "SYS_RESOURCE",
            "SYS_TIME",
            "SYS_TTY_CONFIG",
            "WAKE_ALARM"
        ],
        "Cgroup": "",
        "CgroupParent": "",
        "CgroupnsMode": "private",
        "ConsoleSize": [
            0,
            0
        ],
        "ContainerIDFile": "",
        "CpuCount": 0,
        "CpuPercent": 0,
        "CpuPeriod": 0,
        "CpuQuota": 0,
        "CpuRealtimePeriod": 0,
        "CpuRealtimeRuntime": 0,
        "CpuShares": 0,
        "CpusetCpus": "",
        "CpusetMems": "",
        "DeviceCgroupRules": null,
        "DeviceRequests": [],
        "Devices": [],
        "Dns": [],
        "DnsOptions": null,
        "DnsSearch": null,
        "ExtraHosts": [],
        "GroupAdd": null,
        "IOMaximumBandwidth": 0,
        "IOMaximumIOps": 0,
        "Init": false,
        "IpcMode": "private",
        "Isolation": "",
        "Links": null,
        "LogConfig": {
            "Config": {},
            "Type": "json-file"
        },
        "MaskedPaths": [
            "/proc/asound",
            "/proc/acpi",
            "/proc/interrupts",
            "/proc/kcore",
            "/proc/keys",
            "/proc/latency_stats",
            "/proc/timer_list",
            "/proc/timer_stats",
            "/proc/sched_debug",
            "/proc/scsi",
            "/sys/firmware",
            "/sys/devices/virtual/powercap",
            "/sys/devices/system/cpu/cpu0/thermal_throttle",
            "/sys/devices/system/cpu/cpu1/thermal_throttle",
            "/sys/devices/system/cpu/cpu2/thermal_throttle",
            "/sys/devices/system/cpu/cpu3/thermal_throttle"
        ],
        "Memory": 0,
        "MemoryReservation": 0,
        "MemorySwap": 0,
        "MemorySwappiness": null,
        "NanoCpus": 0,
        "NetworkMode": "bridge",
        "OomKillDisable": null,
        "OomScoreAdj": 0,
        "PidMode": "",
        "PidsLimit": null,
        "PortBindings": {
            "9090/tcp": [
                {
                    "HostIp": "",
                    "HostPort": "9090"
                }
            ]
        },
        "Privileged": false,
        "PublishAllPorts": false,
        "ReadonlyPaths": [
            "/proc/bus",
            "/proc/fs",
            "/proc/irq",
            "/proc/sys",
            "/proc/sysrq-trigger"
        ],
        "ReadonlyRootfs": false,
        "RestartPolicy": {
            "MaximumRetryCount": 0,
            "Name": "no"
        },
        "Runtime": "runc",
        "SecurityOpt": null,
        "ShmSize": 67108864,
        "UTSMode": "",
        "Ulimits": null,
        "UsernsMode": "",
        "VolumeDriver": "",
        "VolumesFrom": null
    },
    "HostnamePath": "/var/lib/docker/containers/95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548/hostname",
    "HostsPath": "/var/lib/docker/containers/95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548/hosts",
    "Id": "95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548",
    "Image": "sha256:1b7bb8fcedf8f72cbd0f0d30e10cb407c72615397149aa15351e5415f003a118",
    "LogPath": "/var/lib/docker/containers/95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548/95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548-json.log",
    "MountLabel": "",
    "Mounts": [
        {
            "Destination": "/linkding",
            "Driver": "local",
            "Mode": "z",
            "Name": "my_docker_data",
            "Propagation": "",
            "RW": true,
            "Source": "/var/lib/docker/volumes/my_docker_data/_data",
            "Type": "volume"
        }
    ],
    "Name": "/linkding",
    "NetworkSettings": {
        "Bridge": "",
        "EndpointID": "480fd4b4a93d594b3b46f58b5865fa5ca8406fc8ccfffd071e8d91d95cee379f",
        "Gateway": "172.17.0.1",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "HairpinMode": false,
        "IPAddress": "172.17.0.3",
        "IPPrefixLen": 16,
        "IPv6Gateway": "",
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "MacAddress": "96:7d:43:ca:da:a7",
        "Networks": {
            "bridge": {
                "Aliases": null,
                "DNSNames": null,
                "DriverOpts": null,
                "EndpointID": "480fd4b4a93d594b3b46f58b5865fa5ca8406fc8ccfffd071e8d91d95cee379f",
                "Gateway": "172.17.0.1",
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "GwPriority": 0,
                "IPAMConfig": {},
                "IPAddress": "172.17.0.3",
                "IPPrefixLen": 16,
                "IPv6Gateway": "",
                "Links": null,
                "MacAddress": "96:7d:43:ca:da:a7",
                "NetworkID": "35cb9409cff8b961154261121631e484739801d4f662e0d0ddadb4648ec216bc"
            }
        },
        "Ports": {
            "9090/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "9090"
                },
                {
                    "HostIp": "::",
                    "HostPort": "9090"
                }
            ]
        },
        "SandboxID": "f441f2eba9953baaa5862b74c9d7fc75aa0c1000aa592353e5d0c78ca8125fd4",
        "SandboxKey": "/var/run/docker/netns/f441f2eba995",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null
    },
    "Path": "./bootstrap.sh",
    "Platform": "linux",
    "Portainer": {
        "ResourceControl": {
            "Id": 5,
            "ResourceId": "95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548",
            "SubResourceIds": [],
            "Type": 1,
            "UserAccesses": [],
            "TeamAccesses": [],
            "Public": false,
            "AdministratorsOnly": true,
            "System": false
        }
    },
    "ProcessLabel": "",
    "ResolvConfPath": "/var/lib/docker/containers/95f144a65861d24c504f4ee444a1170afab2661497b8ed4cc2ddafed89329548/resolv.conf",
    "RestartCount": 0,
    "State": {
        "Dead": false,
        "Error": "",
        "ExitCode": 0,
        "FinishedAt": "0001-01-01T00:00:00Z",
        "Health": {
            "FailingStreak": 0,
            "Log": [
                {
                    "End": "2025-11-03T22:37:55.629625383Z",
                    "ExitCode": 0,
                    "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r100    42  100    42    0     0  19516      0 --:--:-- --:--:-- --:--:-- 21000\n{\"version\": \"1.44.1\", \"status\": \"healthy\"}",
                    "Start": "2025-11-03T22:37:55.56681042Z"
                },
                {
                    "End": "2025-11-03T22:38:25.689704326Z",
                    "ExitCode": 0,
                    "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r100    42  100    42    0     0  19553      0 --:--:-- --:--:-- --:--:-- 21000\n{\"version\": \"1.44.1\", \"status\": \"healthy\"}",
                    "Start": "2025-11-03T22:38:25.631864306Z"
                },
                {
                    "End": "2025-11-03T22:38:55.753886703Z",
                    "ExitCode": 0,
                    "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r100    42  100    42    0     0  20885      0 --:--:-- --:--:-- --:--:-- 42000\n{\"version\": \"1.44.1\", \"status\": \"healthy\"}",
                    "Start": "2025-11-03T22:38:55.69103654Z"
                },
                {
                    "End": "2025-11-03T22:39:25.820627155Z",
                    "ExitCode": 0,
                    "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r100    42  100    42    0     0  20467      0 --:--:-- --:--:-- --:--:-- 21000\n{\"version\": \"1.44.1\", \"status\": \"healthy\"}",
                    "Start": "2025-11-03T22:39:25.75567308Z"
                },
                {
                    "End": "2025-11-03T22:39:55.881677046Z",
                    "ExitCode": 0,
                    "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r100    42  100    42    0     0  20066      0 --:--:-- --:--:-- --:--:-- 21000\n{\"version\": \"1.44.1\", \"status\": \"healthy\"}",
                    "Start": "2025-11-03T22:39:55.821255523Z"
                }
            ],
            "Status": "healthy"
        },
        "OOMKilled": false,
        "Paused": false,
        "Pid": 15420,
        "Restarting": false,
        "Running": true,
        "StartedAt": "2025-11-02T14:34:40.93747436Z",
        "Status": "running"
    }
}

And the volume options on the NFS volume in portainer

Volume details

id: my_docker_data
Mount path: /var/lib/docker/volumes/my_docker_data/_data
Driver; local

Access Control

Ownershitp : Administrators

Volume options

device: :/volume2/my_docker_data
o: ddr=10.33.33.4,rw,noatime,rsize=8192,wsize=8192,tcp,timeo=14,nfsvers=4
type: nfs

Containers using volume

linkding
mounted at /linkding
read-only: false

I posted earlier but I guess the output from the full inspect was too long so my post was hidden.

Here is the shorted version

Output from docker container inspect

[
  {
    "Type": "volume",
    "Name": "my_docker_data",
    "Source": "/var/lib/docker/volumes/my_docker_data/_data",
    "Destination": "/linkding",
    "Driver": "local",
    "Mode": "z",
    "RW": true,
    "Propagation": ""
  }
]

And the volume options on the NFS volume in portainer

Volume details

id: my_docker_data
Mount path: /var/lib/docker/volumes/my_docker_data/_data
Driver; local

Access Control

Ownershitp : Administrators

Volume options

device: :/volume2/my_docker_data
o: ddr=10.33.33.4,rw,noatime,rsize=8192,wsize=8192,tcp,timeo=14,nfsvers=4
type: nfs

Contaienrs using volume

linkding
mounted at /lingding
read-only: false

The spam filter blocked it. Possibly because of its length, and we were not available yet to accept it. I did it now, so you can see one of your original, blocked posts (one was a duplicate of the other, so I deleted one)

Regarding your issue, I see you shared the volume options. It shows you indeed created an NFS volume, so you don’t need to mount the NFS folder to the host.

I also see that you mounted the folder to “/linkding” inside the container. Does the container write that folder or “/etc/linkding” that I see in the PATH?

Since an NFS mount also means that Docker would mount the remote filesystem at /var/lib/docker/volumes/my_docker_data/_data which is mounted into the container, you could check if that mount on the host works in the docker data root. You should see the same files on NFS, in /var/lib/docker/volumes/my_docker_data/_data and in the container under /linkding.

I checked the /linkding with

docker exec -it “container id” ls /etc/linkding

and I see the files in there for linkding. So it appears to be writing to that location

As for

/var/lib/docker/volumes/my_docker_data/_data,

that location has a

/linkding with the test.txt file inside

and an opts.json file. So not sure what that means?

within the json file is has

{“MountType”:“nfs”,“MountOpts”:“addr=10.33.33.4,rw,noatime,rsize=8192,wsize=8192,tcp,timeo=14,nfsvers=4”,“MountDevice”:“:/volume2/my_docker_data”,“Quota”:{“Size”:0}}

And by “Host” do you mean the Ubuntu server?

But under

/var/lib/docker/volumes/my_docker_data/_data/linkding

I created a test.txt file at that location and that shows in the NFS share on my Synology. So clearly I set something up incorrectly or pointed the container to the wrong location?

You are still using the wrong directory in the container. You mount to /linkding and write to /etc/linkding

I guess I don’t understand then what is happening. When I set up the container I specify /linkding under volume mapping in the container field. Then why does it create it under /etc/linkding? If I set the container path in portainer to /etc/linkding during creation, it fails to start.

If I set the container field in portainer to the

/var/lib/docker/volumes/my_docker_data/_data/linkding

directly, where I know its writing to the Synology, it still sets up the working directory to /etc/linkding and writes to that directly and not the Synology.

I clearly do not understand how this is working

Inspecting the container I see these paths:

Binds:[

“my_docker_data:/var/lib/docker/volumes/my_docker_data/_data/linkding”

],

and

Volumes:{

/var/lib/docker/volumes/my_docker_data/_data/linkding:{}

},

WorkingDir:“/etc/linkding”

},

This is the directory that is writing to the Synology

/var/lib/docker/volumes/my_docker_data/_data/linkding

because it has the test.txt that is also present on the Synology NFS share.

So I guess I don’t understand how to get this to write to the Synology

So actually my question is this:

In portainer, Under the advance container settings,then volumes, There are two fields to fill out.

Container:
Volume:

Under container: I put /linkding (or anything really) and it always sets the container up the same way
Under Volume : I choose the NFS share.

So for example I just now created a new container and put the following:

Container: /link
volume: my_docker_data

So what is the Container path /link doing?

Becasue now all the data for the linkding container is here, again.

/var/lib/docker/volumes/my_docker_data/_data/linkding

If I go into the directory here

/var/lib/docker/volumes/my_docker_data/_data

and create a test folder then the test folder shows on the Synology

/var/lib/docker/volumes/my_docker_data/_data/test

So then why does the folder created by portainer not show up on the NFS share

this one

/var/lib/docker/volumes/my_docker_data/_data/linkding

Is that inside the container? If so I can’t find it when I look in the files within the container.
If its not inside the container then were do I find it within the Ubuntu server?

I seriously want to understand this but cannot wrap my head around what docker is doing behind the scene.

Also, what would I put in the container field so the container will write to the NFS share, instead of somewhere else?

Okay sorry for all the replies but just trying to figure this out and stumbled on this.

When I go into the container through the container console in portainer, it drops me into /etc/linkding directory. But if I back out to the root / of the container then I find the /link folder and that folder can write to the Synology. So that just further confuses me?

Seems like you need some basic Linux skill as well. When you work with Linux containers, you need to understand a little bit how Linux works. “/” means the root directory. Like the rot of “C:\\” on Windows. When you mount a volume or any folder from the host, you always use an absolute path from the root in the container. Mounting to “/linkding” will always mean from the root, and it has nothing to do with where you are when you open a terminal in the container.

A workdir in a container is exactly what the context of a command will be unless using “cd” to change directory. When you open a terminal in a container, that is basically running a “bash” or any other command that opens a shell for you, but the current directory will be the one dfined in the “workdir”. It is defined when you create the image from which you create the container, or you can override when you create the container. You don’t have to!

A volume is not something that is mounted for an interactive user. We usually don’t even open terminals in containers unless debugging or learning about it. Volumes are for the processes for which you created the container, so they can read and write it. And those can read /linkding or anything else assuming they have permission to do so. But that would be another topic.

So what you see is normal. The volume is exactly where you defined it to be. And /etc on linux is for configuration files. Not really for data. I don’t know that app you are using in the container and I did not try to learn about it, but you can still decide wheter you want to change the container definition and mount to /etc/linkding/data for example or leave the volume where it is. It all depends on what the application requires.

I guess I don’t understand why when I specify

/link

as the container path under the Advanced container settings section in portainer, and then when the container is set up and running, the location of all the files that make up the container is located at

/etc/linkding

and the

/link

is the one writing to the Synology.

If you map a volume into a container path, it just mounts a piece of storage from outside the container filesystem, into a target path inside the container filesystem.

The application inside the container does not know that something is mounted into the container filesytem. The usual approach is to check the image description to see what container paths are supposed to be mapped as volume to persist data outside the container If you map a volume into a different container path, then you will need to learn how to configure the application inside the container to use the custom path instead. Use the later approach only if you realy know what you are doing.

When I lookup the image description for sissbruecker/linkding there is a link to the docs, which indicate that you are mapping your volume in the wrong container path.

The expected container path is /etc/linkding/data. It is not /linkding and not /etc/linkding.

Hello,

Yes thank you for this. When I use the correct path I see the data on the Synology. Only issue is that it writes all the files to the storage on the synology but its not in a folder specific to that container. Is there a way to get it to write to a folder instead of to the whole volume?

For example, I have linkding and meTube containers working and the data for both containers is writing to the SNF folder on the Synology but all the files for both containers are all mixed together on the share, there is no separation by container?

It does, because you configured this in your volume:

Sure, there are two ways:

  1. create the matching subfolders underneath /volume2/my_docker_data and create volumes that poit to the subfolder in the device configuration. You will end up with a volume per subfolder.
  2. Docker engine version > 26.0 understand subpath (at least in docker compose) to mount a subfolder of a mounted volume. Never tried it with nfs though. The modified Docker Engine that Synology’s Container Manager embedds is afaik too old to support this feature.