Table of Contents
What is a Volume?
The Volume feature in FilingBox MEGA is a logical management unit that maps a specific directory to its corresponding application access policy.
To securely manage data stored in a specific directory on a device via the server and to control which apps can access that data, a Volume must be created.
In short, a Volume is the basic configuration unit that defines 'which directory (Where)' can be used by 'which app (Who)'.
Mount
Mount is the process of linking (Mounting) a device's actual directory path to the created logical Volume.
A Volume that has only been created is inactive; it must be activated by mounting a specific directory path. Once the Volume mount is complete, the Volume represents the data in the defined path, and "Allowed App Management" for that Volume becomes available.
Mount Ownership Settings
When mounting a Volume, FilingBox MEGA requires 'Device Administrator Authentication'. The Device Administrator ID entered during authentication is a key factor in determining the Linux Operating System (OS) ownership (Owner/Group) of the mounted directory.
- If the ID matches an existing user account in the Linux system: If the entered 'Device Administrator ID' is identical to an existing user account on the host's Linux system (e.g., mysql, tomcat), the ownership of the mounted directory will automatically be set to that Linux user and group. (e.g., owner: mysql, group: mysql)
- If no matching account exists in the Linux system: If the ID does not correspond to an existing account on the Linux system, the directory will be mounted with root ownership by default.
Necessity and Benefits of Ownership Settings
This ownership setting feature is essential for system security and application compatibility.
Ensuring Application Compatibility
Most server applications (e.g., MySQL, PostgreSQL, Nginx) run as a specific system account (e.g., mysql, tomcat) instead of root for security reasons. These applications require proper read/write ownership of their data directories (e.g., /var/lib/mysql).
If the /var/lib/mysql directory were mounted with root ownership, the DB server running as the mysql user would fail to start due to 'Permission Denied' errors, as it cannot access its files, even if the necessary app was added to the Volume's allowed app list.
Therefore, specifying the correct 'Device Administrator ID' (e.g., mysql) during the mount process is mandatory to ensure the application runs normally.
Multi-Mount
Multi-Mount is the practice of creating separate, individual Volumes for multiple directories to operate them independently.
Necessity of Multi-Mount
The primary purpose of using Multi-Mount is to isolate and manage access permissions (App Permission) on a per-directory basis.
If all directories were mounted under a single Volume, every app permitted for that Volume would gain access to all sub-directories. However, Multi-Mount allows you to selectively permit only the necessary apps for each specific Volume (directory).
[Multi-Mount Use Case Example]
Volume A (Path: /data/system_logs)
- Allowed Apps: 'Log Analyzer App', 'Backup Solution App'
Volume B (Path: /data/user_documents)
- Allowed Apps: 'Document Editor App', 'Cloud Sync App'
With this configuration, the 'Document Editor App' cannot access system logs, and the 'Log Analyzer App' cannot access user documents.
As shown, Multi-Mount is essential for enhancing system security and stability by segregating access policies based on the data's purpose and security level.
Auto-Mount
FilingBox MEGA supports an Auto-Mount feature to ensure service continuity by automatically restoring Volume mount states after a system reboot.
Necessity of Auto-Mount (Preventing Service Disruption)
If a Volume is mounted to a directory that is used by a registered service (app), the Linux client will automatically re-mount that Volume even if the Linux system reboots.
This feature ensures that related application services can start automatically without disruption, removing the need for an administrator to manually mount Volumes after every reboot.
Important
Service Start Order (Required)
To ensure Auto-Mount compatibility with registered services, the Linux client (which is also registered as a service for auto-mounting) must start before the application services that access the Volume (e.g., mysqld.service).
If the application service starts before the Volume mount is complete, it will fail to start because it cannot access its required data.
Therefore, in a systemd environment, you must configure the Before= dependency to ensure the Linux client service starts before the dependent services.
Comments
Article is closed for comments.