执行setTrashed(true)触发Exception: Access denined: DriveApp权限问题求助

问题核心 #

你编写的脚本在执行旧文件删除逻辑时，非管理员账号首次运行触发Exception: Access denined: DriveApp，但同一账号二次运行正常。根源在于：

• 首次运行时，待删除的旧文件由管理员（或其他账号）创建，且未对该非管理员开放任何权限；非管理员既无法直接删除，也无权通过Drive.Permissions.insert给自己添加权限（该操作需文件所有者或权限管理角色）。
• 二次运行时，待删除的旧文件是该账号上一次运行生成的，即便所有者是管理员，系统自动赋予了该账号编辑权限，因此可正常执行删除。

可行解决方案 #

1. 预配置文件夹权限（推荐） #

让管理员设置目标文件夹的权限继承规则，确保所有文件自动对需要运行脚本的账号开放编辑权限：

• 打开目标文件夹，点击右上角「共享」
• 添加目标账号/组织群组，设置角色为「编辑者」
• 勾选「应用到现有文件」，覆盖旧文件权限配置

此方式一劳永逸，非管理员账号可直接对文件夹内所有文件执行setTrashed(true)操作。

2. 脚本内添加权限容错逻辑 #

若无法预配置权限，可在删除逻辑中加入异常捕获，跳过无权限的删除操作：

function tryDeleteOldFile(oldDocId) {
  try {
    const oldFile = DriveApp.getFileById(oldDocId);
    oldFile.setTrashed(true);
    console.log(`已删除旧文件: ${oldDocId}`);
  } catch (error) {
    if (error.message.includes('Access denied')) {
      console.log(`无权限删除文件 ${oldDocId}，跳过该操作`);
    } else {
      // 抛出其他类型的异常
      throw error;
    }
  }
}

3. 采用服务账号执行删除操作（进阶） #

若必须删除所有旧文件，可创建一个由管理员授权的服务账号，授予其目标文件夹的所有者权限，脚本通过服务账号的OAuth凭据执行删除逻辑。该方式配置较复杂，适合需要严格权限管控的场景。

内容的提问来源于stack exchange，提问作者Andy Nguyen