Skip to main content

Fylad System Administration Guide

This document is the official Administrator guide for managing the Fylad system — an enterprise File Sharing platform that provides storage, access control, and operation approval workflows through a centralized platform. The purpose of this guide is to help Administrators transform the organization's structure into a controllable model within Fylad, rather than simply learning the available software options. The primary audience is system administrators responsible for access design, storage management, and user activity monitoring.

Introduction​

Fylad acts as the organization's centralized file repository — a centralized platform for storing, sharing, and managing the file lifecycle at the enterprise level. Unlike traditional approaches where files are stored across distributed File Servers and access is controlled through operating system Permissions or Active Directory, Fylad integrates these layers into a single platform.

The key responsibility of the Administrator is to design the access and file storage structure in a way that users have access only to the resources they need, sensitive operations require approval when necessary, and activities remain auditable and reportable.

Info

Fylad is a tool for implementing organizational policies, not a fixed model imposed on organizations. The design of organizational units, Permission levels, and the use of Approval should be based on the security policies of each organization.

The Problem Fylad Solves​

In traditional File Sharing environments, files are usually distributed across multiple network Shares, while access control depends on a combination of File System Permissions and Group Policies — an approach that quickly becomes complex and difficult to audit as the organization grows. Fylad provides this process through a centralized system with a unified access model.

Within this centralized model, the Administrator can manage users and groups, create an organizational structure, create Share Storage, define file operation Permissions (Upload, Download, Remove, Access, Share Link), configure Approval, enforce user and file limitations, and monitor the status of security services such as Antivirus engines.

Overall Fylad Architecture​

Fylad's architecture can be viewed as a layered model — authentication mechanisms and organizational structures are located at the lowest layer, while monitoring and security interfaces used by the Administrator are located at the highest layer.

Internal Fylad usersLocal UsersInternal Fylad usersIntegrated with DirectoryLDAP UsersIntegrated with DirectoryNested organizational structureFylad GroupNested organizational structureFile storage spaceShare StorageFile storage spaceDirect file sharingLink SharingDirect file sharingUpload / Download / Remove / Access / SharePermissionsUpload / Download / Remove / Access / ShareApproval of sensitive operationsApprovalApproval of sensitive operationsUser & Fylad QuotaQuotaUser & Fylad QuotaMulti-engine scanningMulti-AVMulti-engine scanningBehavioral file analysisSandboxBehavioral file analysisAudit and monitoringReport & SessionsAudit and monitoringService statusMonitoring ServerService status
Tip

Before creating any Share Storage, first understand the organization's user and group structure. The Group design forms the foundation for all subsequent access decisions.

Identity and Access​

Fylad supports two identity sources: Local Users, which are defined directly within Fylad, and LDAP Users, which are retrieved from an external Directory such as Active Directory — meaning that instead of defining users again, Fylad connects to the organization's central directory.

The choice between these two depends on the organization's identity management model. In organizations that have a central Directory, LDAP is generally the preferred option so that the user lifecycle — hiring, department changes, and employee departures — can be managed in a single location.

Organizational Structure and Fylad Group​

Fylad Group is a logical container for grouping users and, more importantly, enables nested structures — meaning that an organizational tree similar to the organization's actual structure can be created.

For example, the Information Technology department can include Software, Hardware, Network, and Programming sub-units, with each sub-unit having its own Share Storage:

organizational-tree.txt
Information Technology
├── Software
│ ├── Ali's Share Storage
│ ├── Reza's Share Storage
│ └── Shared Software Share Storage
├── Network
│ ├── Mehdi's Share Storage
│ ├── Hossein's Share Storage
│ └── Shared Network Share Storage
└── Hardware
├── Ahmad's Share Storage
└── Shared Hardware Share Storage

This nested model enables resource separation between departments, management-level access control for each unit, and detailed reporting based on the organizational structure.

Share Storage​

Share Storage is the primary Fylad component for storing and sharing files — what end users typically recognize as a "drive" or "shared folder", but with a complete access control and auditing layer on top of it. The Administrator can define any number of Share Storage instances for each organization, department, or business scenario.

Share Storage Use Cases​

A Share Storage can be a personal space — for example, Ali's Share Storage, where a specific user is the primary owner — or a shared space, such as Shared Software Department Share Storage, where multiple users have access. The choice between these models depends on the operational scenario and the department's collaboration policy.

Creating a Share Storage​

Creating a Share Storage involves three key decisions: the name, the list of users or groups with access, and the Permissions assigned to each of them.

  1. From the main menu, navigate to Share Storage.
  2. Select Create.
  3. Enter a meaningful Name that reflects the organizational structure.
  4. Add the authorized Users / Groups.
  5. Define the Permissions for each member (Upload, Download, Remove, Access, Share Link).
Tip

Instead of adding users individually to a Share Storage, use Groups whenever possible. When a new user joins a department, they only need to be added to the appropriate Group, eliminating the need to modify permissions across individual Storage instances.

Department Manager Access​

In many scenarios, a department manager needs full access to all Share Storage instances belonging to their department — both for monitoring and for troubleshooting when the primary user is unavailable. This access is typically configured as Full Access and covers all operations across the department's Storage instances.

Warning

Full access for a department manager is a common pattern, but it is not mandatory. The manager's access level must be determined according to the organization's privacy and security policies, because in some organizations even department managers should not be able to view the contents of a user's personal storage.

Permissions​

Permissions in Fylad define the operations that each user or group is allowed to perform on a Share Storage — similar to placing a list of permitted actions on each door. The five primary Permissions are:

PermissionDescription
AccessAllows the user to view and enter the Share Storage
UploadAllows uploading a new file to the Storage
DownloadAllows downloading a file from the Storage
RemoveAllows removing a file from the Storage
Share LinkAllows creating a direct file-sharing Link

Combining these Permissions allows the Administrator to create precise roles such as "read-only", "upload-only", or "full administrator" without relying on predefined roles.

Approval​

Approval is a mechanism in which an operation requires approval from one or more other users in addition to having the required Permission — similar to a manager signing off on a leave request. Approval is used when an operation is considered sensitive and the organization wants to add a human review layer.

The general flow of an operation requiring Approval is as follows:

  1. A user who has the required Permission requests the operation.
  2. Fylad determines that the operation requires Approval and places the request in the approval queue.
  3. The Approver (or Approvers, according to the configured sequence) reviews the request.
  4. Once all required approvals are completed, the operation is actually executed.

Approval can be defined for Upload, Download, and Remove operations, and its usage pattern is determined entirely by the organization's policies.

Approver​

An Approver is a regular system User who is selected by the Administrator to approve requests. When defining an Approval, the Administrator can specify one Approver, multiple Approvers, and their Priority order.

Single-Level Approval​

The simplest Approval configuration is a single Approver. In this model, approval from that one person is sufficient for the operation to be executed and is suitable for scenarios where only one level of oversight is required — for example, approval from a direct manager.

Multi-Level Approval​

When multiple Approvers with different Priorities are configured, the request moves sequentially from the lowest Priority to the highest, and all Approvers must approve the request before the operation is executed. This model is suitable for highly sensitive operations such as bulk file removal or downloading confidential files.

Warning

In multi-level Approval, rejection by any Approver at any stage stops the entire request. When designing Priority levels, always consider Approver availability to prevent the workflow from becoming blocked when one person is unavailable.

User Quota​

User Quota deals with limitations related to user Login — specifically, who can log in, when they can log in, and from where they can log in. This Quota is not related to file size or operational usage; it only controls login conditions.

Two common types of User Quota are:

  • Login time restriction for defining permitted login time ranges (for example, only during business hours).
  • IP restriction for specifying permitted or prohibited IP addresses or ranges during Login.

Fylad Quota​

Unlike User Quota, Fylad Quota controls limitations related to file operations and consumption — similar to a usage allowance for each user or group. The following three dimensions can be limited:

  • Upload volume
  • Download volume
  • File size (the maximum permitted size of an individual file)

Quota can be applied at the User level (a specific user) or at the Group level (a collection of users). In large organizations, applying Quota at the Group level is generally more scalable.

When a user has the Share Link Permission, they can share a specific file directly with another person without granting access to the entire Share Storage — an experience similar to sharing a file link through cloud services.

The Link Management section is the Administrator's management interface for viewing, reviewing, and, when necessary, revoking Links created throughout the system. This section is critical for auditing and ensuring that files are not unintentionally exposed or leaked externally.

Security

Sharing Links are one of the most common paths for information leakage. Periodically review Link Management and remove unused or expired Links.

Recycle Bin​

Recycle Bin is the mechanism for recovering deleted files — similar to an operating system's recycle bin, but implemented at the system level with configurable policies. The Administrator can determine how deleted files are handled: retained for a specific period or permanently deleted immediately.

Recycle Bin settings should be configured according to the organization's Retention Policy — excessive retention can create security risks, while insufficient retention may conflict with legal or regulatory requirements.

Report​

Report is the central component for auditing user activity in Fylad. The Administrator can extract and analyze the history of operations performed by users, and each record typically includes:

  • User who performed the operation
  • Date and exact time of the operation
  • Action performed (Upload, Download, Remove, Share, etc.)
  • File targeted by the operation

Report plays a key role in responding to security incidents and conducting internal audits — meaning that if an incident occurs, the Administrator can determine exactly who performed which action.

Sessions​

The Sessions section displays a live list of users' active Sessions. The Administrator can see which users are currently logged into the system, from which IP address and since when, and can terminate a suspicious Session when necessary.

Multi-AV and Sandbox​

Fylad checks uploaded files for security before they are permanently stored — this layer is essential for preventing malware from entering the organization's Storage. The two primary components of this process are Multi-AV, which scans files in parallel using multiple Antivirus engines, and Sandbox, which evaluates file behavior in an isolated environment.

The Sandbox section in the Administrator interface displays the list and status of configured Antivirus Instances. This section can be used to ensure that all security engines are healthy and operational.

Security

If an Antivirus engine becomes unavailable, Fylad may scan files without complete security coverage. The status of Sandbox and Multi-AV should be part of the Administrator's daily checklist.

Monitoring Server​

Monitoring Server displays the overall status of the server, Fylad services, and connected Storage — serving as a central point for quickly detecting infrastructure problems before users become aware of them. The Administrator should make this section part of their daily monitoring routine.

Organizational Boundary​

The access structure between departments in Fylad does not follow a single mandatory pattern. Each organization can determine, based on its security policies and internal processes, which departments users can see, who is allowed to perform File Sharing, and whether cross-department access should be direct or require Approval.

This flexibility means that the Administrator should not treat a specific Workflow as the "correct" method. The design should be based on the organization's actual requirements, and the following items should be explicitly defined:

  • Structure of departments and sub-units
  • Cross-department access model
  • Where Approval is required and who the Approvers are
  • Permitted sharing methods (internal and external)
  • Permission levels for different users
  • How Groups should be used for scalability
Info

Fylad is an organizational policy implementation tool, not a ready-made policy. An Administrator's success depends on their ability to translate organizational requirements into the Fylad model, rather than simply knowing the name of every available option.

Summary​

  • Fylad is a centralized enterprise File Sharing system that integrates Identity, Storage, Permission, Approval, and security inspection into a single platform.
  • Share Storage is the primary unit for file storage and sharing. It can be personal or shared, and its design should be based on departmental structures and implemented through Fylad Group.
  • The five Permissions (Access, Upload, Download, Remove, Share Link) form the foundation of access control and should preferably be applied at the Group level rather than individually at the User level.
  • Approval, whether single-level or multi-level, provides human oversight for sensitive operations. In multi-level Approval, all Approvers must approve the request.
  • User Quota controls Login conditions, while Fylad Quota limits file consumption and operational volume.
  • Report, Sessions, Multi-AV, Sandbox, and Monitoring Server are monitoring and security tools that should be included in the Administrator's daily checklist.
  • Fylad is a tool for implementing organizational policies, not a fixed model; an Administrator's success depends on accurately translating organizational policies into the Fylad model.