The most common file-level permission mistake is treating overall knowledge base visibility as file visibility: once a member can enter the knowledge base, people assume they can read every file. The correct decision order is to first confirm member identity authentication, then confirm file read permissions, then check whether retrieval is filtered by member-readable files, and only lastly handle deletion actions, since deletion belongs only to the creator.
Member Identity Authentication Is the Entry Point to File-Level Permissions
File-level permissions are a commercial feature enabled by a knowledge base administrator. Knowledge base read permission remains a prerequisite for file access, and retrieval filtering applies when authenticated as the current member. The FastGPT v4.17.2 official documentation places knowledge base members and file permissions within the same decision set: before a member enters the knowledge base, identity must first be confirmed, and identity determines which files can subsequently be seen. During configuration, first verify whether the member belongs to that knowledge base, then verify the member's role within the knowledge base, because different roles affect the outcome of file read permission decisions. Many teams configure only the visibility scope at the knowledge base level without aligning member identity with file read permissions, so members can open the knowledge base but cannot see the expected files. Verification actions can be arranged as follows: log in with the target member account, enter the knowledge base file list, and observe whether the list shows only files readable by that member; then switch to another member account and compare the differences between the two lists. Failure symptoms are usually an empty list, missing file entries, or a no-permission prompt. When identity authentication does not pass, subsequent file read permissions, retrieval filtering, and deletion decisions do not enter the execution stage, so this step must be confirmed first.
File Read Permissions Determine Which Files Members Can See
File read permissions are the core of file-level permissions. The official documentation states that a member's read permission for an individual file is independent of overall knowledge base permissions; having knowledge base access does not mean having read permission for all files. During configuration, confirm read permission ownership file by file, open files that need to be shared to the corresponding members, and narrow the scope of files intended only for specific members. The verification action is to have the member locate the target file in the file list, try to open and view its content, and then try to hit that file's content through retrieval. If the file read permission is not open, the member cannot see the file in the list, and retrieval will not return content snippets from that file. Common failure symptoms are members reporting that files exist in the knowledge base but they cannot see them, or that a certain document is missing from retrieval results. The handling order is to first confirm that member identity authentication passes, then return to file read permissions and verify them one by one. When there are many files, verifying by member group is more efficient than verifying file by file: first list the set of files a member should be able to read, then compare it with what the list actually displays.
Deletion Is Creator-Only; Other Members Cannot Delete on Their Behalf
The permission boundary for deletion actions is decided separately from read permissions. The official documentation clearly states that deletion is creator-only, meaning that whoever created the file is the one who executes the deletion action; other members, even if they have read permission for that file, cannot delete it on the creator's behalf. During configuration, there is no need to assign deletion permissions separately; creator identity itself determines deletion eligibility. The verification action is to have a non-creator member attempt to delete the target file and observe whether the operation is rejected; then have the creator member perform the deletion and confirm it can be completed. There are two types of failure symptoms: one is that a non-creator sees the delete entry but the operation fails, and the other is that the creator cannot find the delete entry, the latter usually being related to member identity authentication or interface state. In team collaboration, the file creator should be agreed upon in advance to avoid a situation where no one can delete files after the creator leaves or their account is deactivated. If ownership really needs to be adjusted, it should be handled at the member identity level, and the deletion restriction must not be bypassed by opening read permissions to other members.
Retrieval Is Filtered by Member-Readable Files
The retrieval stage is likewise constrained by file-level permissions. The FastGPT v4.17.2 official documentation points out that retrieval is filtered by member-readable files: when a member initiates retrieval, the system recalls content only within the scope of files for which that member has read permission. With file-level permissions enabled and current-member authentication in use, retrieval is filtered by the files that member can read. A workflow with a preselected knowledge base and no member-identity authentication still recalls according to knowledge base permissions. The verification action is to have a member initiate retrieval with the same question and compare whether the returned snippets come only from files readable by that member; then have another member retrieve with the same question and compare the differences between the two results. If content from files the member cannot read appears in retrieval results, it indicates that the file read permission configuration and retrieval filtering are inconsistent, and check file read permissions one by one. Common failure symptoms are that members cannot retrieve documents that should be visible, or that retrieval results are mixed with files exclusive to other members. The troubleshooting order is to first confirm member identity authentication, then confirm file read permissions, and finally confirm whether retrieval is filtered by member-readable files.
String the Four Mechanisms into a Verification Checklist
Stringing together member identity authentication, file read permissions, creator-only deletion, and retrieval filtered by member-readable files into a single verification checklist can cover the main scenarios of file-level permissions. The recommended configuration order is as follows: first confirm member identity authentication, then confirm read permissions file by file, then verify retrieval filtering results, and finally confirm that deletion actions belong to the creator. The verification actions can be fixed as three steps: use a member account to view the file list, use the same question to initiate retrieval, and use a non-creator account to attempt deletion. Failure symptoms are categorized by mechanism: a missing list corresponds to read permissions, missing retrieval corresponds to filtering, and deletion failure corresponds to the creator restriction. When implementing this in a team, write this checklist into the knowledge base maintenance process and execute it once after each new member or new file is added; this can reduce repeated troubleshooting caused by permission mismatches.
The Actual Order for Permission Verification
When verifying permissions, first determine member identity, then confirm the file set, and only then look at retrieval and Q&A results. Member identity determines which teams and knowledge bases the member can enter; the file set determines which materials the member can actually read; retrieval returns candidates only within this set. If the three steps are reversed, judgment errors such as "can search but cannot open" or "opening someone else's material" will occur.
File-level permissions filter file by file according to what the member can read, and team administrators do not bypass this layer; team owners and system root are regarded as having all permissions on all files. Adding a member to a team only expands the visible scope and does not equal granting edit or delete rights; deletion can be executed only by the creator. File-level permissions take effect only when authenticated as the current member identity: after file-level permissions are enabled in the commercial edition, filtering occurs only when both knowledge base read permission and member identity are satisfied. Share links and no-login windows follow their own authentication paths; if a knowledge base is preselected and authentication is not performed by member identity, file-level filtering does not apply, and the permission settings for that scenario need to be verified separately.
For acceptance, prepare three types of samples: files readable only by oneself, files readable by others in the same team, and completely unrelated files. Use the three identities to retrieve the same question separately, record the returned files and original snippets, and then compare them with the set itself. If out-of-bounds returns occur, check the file set and member identity first, then check the retrieval configuration; do not change retrieval parameters first.