Kwantum with openmediavault (OMV)

[fschuhmacher]

OMV uses “Filesystems” and “Shared Folders” as its basic file structure.
A filesystem is named according to the pattern “/srv/dev-disk-by-uuid-e...b8a6c”, and a Shared Folder underneath it is therefore:
“/srv/dev-disk-by-uuid-e...b8a6c/example-Shared-Folder”.

Almost all administration settings and plugins in OMV refer to Shared Folders. Paths below that level are unknown to the system.

With Kwantum, you can also edit paths at the level directly beneath the filesystem, which in OMV would correspond to “Shared Folders”. However, those paths would then not be recognized or known as deleted by OMV and could not be used there. I consider the consequences critical.

Therefore, I create Shared Folders exclusively in OMV and use Kwantum only at least one level below. To ensure this, I map the following in Filebrowser’s docker-compose:

volumes:

• ${FS1}/example-Shared-Folder-1:/FS1
• ${FS2}/example-Shared-Folder-2:/FS2
• ${FS3}/Kameras/forall:/SF3/family/all
  ...
  with the following entries in the global env file:
  FS1=/srv/dev-disk-by-uuid-e...b8a6c
  ...

Here is my Docker-Compose:

filebrowser

networks:
filebrowser-net:
name: filebrowser-net

services:
filebrowser:
container_name: filebrowser-quantum
image: gtstef/filebrowser:0.8.10-beta
restart: unless-stopped
ports:
- "xxx:80"
environment:
FILEBROWSER_ONLYOFFICE_SECRET: ${JWT_SECRET}
FILEBROWSER_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
TZ: ${TZ}
volumes:
- ${HOMES}/Homes:/HOMES/HOMES
- ${DOCKER}:/DOCKER
- ${RSYNC}:/RSYNC
- ${RSNAPSHOT}:/RSNAPSHOT
- ${KAMERAS}/Kameras:/KAMERAS/KAMERAS
- ${DIVERS}:/DIVERS
- ${DATA}/filebrowser/config.yaml:/home/filebrowser/config.yaml
- ${DATA}/filebrowser/database.db:/home/filebrowser/database.db
- ${DATA}/filebrowser/data:/data
networks:
- filebrowser-net
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 30s
timeout: 10s
retries: 5

onlyoffice:
container_name: onlyoffice-docserver
image: onlyoffice/documentserver
restart: unless-stopped
ports:
- "851:80"
environment:
JWT_ENABLED: ${JWT_ENABLED}
JWT_SECRET: ${JWT_SECRET}
JWT_HEADER: ${JWT_HEADER}
networks:
- filebrowser-net
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 30s
timeout: 10s
retries: 5

[gtsteffaniak]

"Kwantum" thats a new one.

To summarize the issue:

However, those paths would then not be recognized or known as deleted by OMV and could not be used there. I consider the consequences critical.

you are saying when a share path no longer exists it sticks around? Do you have an example?

[destlion]

Example 1: I create a shared folder in OMV via Storage → Shared Folders → Create with the following settings: name testfolder, filesystem sdd1, and permissions set to Administrator: read/write, Users: read/write, Others: read-only. The path to this testfolder is now /srv/dev-disk-by-uuid-9c4ec12e-4252-4af3-be0e-f047dea12422/testfolder. I can now also see this folder in Quantum, edit it, and even could delete it. In OMV I then make several configurations that relate to this folder (ftp/sftp/antivirus/compose/rsnapshot, etc., all refer to shared folders). In this example, I did this with the SMB service. OMV shows me where this shared folder is being used; in my example, testfolder is listed under services->smb->shares->share with root:users 2775 as permissions. For the docker-data folder that is in use, OMV shows, for example, that it is referenced by services->clamav->jobs->job, services->compose, services->rsnapshot->jobs->job->src, services->rsync->jobs->job->src, and services->smb->shares->share, with the full path /srv/dev-disk-by-uuid-c4a37179-3bca-4e6e-b3e9-cbf532a68a49/docker-data and permissions root:users 2777. I can only delete shared folders in OMV once I have removed these service assignments. That’s probably the crucial point! I have now deleted testfolder in Quantum, which is no problem at all from there. In OMV this is not detected; the folder is still shown. On my laptop, the folder is also still shown via SMB, and of course an error message appears when I try to open it. The associated services will probably all end up in an error state as well.

Example 2: If I create testfolder-2 at the same level in Quantum, it does not appear in OMV at first. If I then create a folder with the same name on the same device in OMV, everything seems to work; at least via SMB I can see the contents that I previously copied into it with Quantum.

Conclusion: It looks like deleting a shared folder that was created in OMV from within Quantum is quite dangerous.

[fschuhmacher]

Am 13.11.25 um 20:47 schrieb Graham Steffaniak:

…

"Kwantum" thats a new one. To summarize the issue: However, those paths would then not be recognized or known as deleted by OMV and could not be used there. I consider the consequences critical. you are saying when a share path no longer exists it sticks around? Do you have an example? — Reply to this email directly, view it on GitHub <https://github.com/ gtsteffaniak/filebrowser#1433#discussioncomment-14962172>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ AN7XLUOEWOMXCLXYDUVGLPD34TN6RAVCNFSM6AAAAACKGGJ37SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJWGIYTOMQ>. You are receiving this because you authored the thread.Message ID: <gtsteffaniak/filebrowser/repo-discussions/1433/ ***@***.***>