粘滞位生效需目录对其他用户有执行权限（o+x），否则显示大写t且实际无效；chmod 1777一步到位设rwx+粘滞位，而chmod +t仅追加不补x；sgid配合粘滞位可解决共享目录新文件属组继承问题。
直接给目录加 chmod +t 不够，必须同时保证其他用户有执行权（o+x），否则会看到大写 T，粘滞位实际不生效。
为什么 chmod +t 后还是能删别人文件？
常见现象：执行了 chmod +t /data/temp，ls -ld 却显示 drwxrwxrwT（末位大写 T）。这说明粘滞位已设，但其他用户缺执行权限（x）——而 Linux 要求目录有 x 才能遍历、删除其中文件，没 x 就连 rm 命令都进不去目录，更别提删文件；但一旦补上 o+x，T 就变 t，防删逻辑才真正启动。
- 粘滞位只在目录有执行权时才起作用，
T是“无效启用”状态 - 很多脚本或自动化部署漏掉这步，导致看似配置了却白忙
-
chmod 1777一步到位，因为它隐含了o+x
chmod 1777 和 chmod +t 的实际区别
两者都能设粘滞位，但底层行为不同：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
chmod 1777 /path：强制重置为所有用户rwx+ 粘滞位，覆盖原有权限位，最稳妥 -
chmod +t /path：只追加粘滞位，不改动已有读写执行权限；若原权限是775，结果就是1775（即drwxrwxr-x→drwxrwxr-t），但此时其他用户没x，仍会显示T - 生产环境推荐用
1777，尤其对纯临时目录；若需限制其他用户读取，则改用2775+ SGID（见下一条）
团队共享目录要不要加 SGID？
单靠粘滞位只能防误删，不能解决新文件属组混乱问题。比如用户 A 创建 report.txt，默认属组是其主组，不是团队组，其他人可能无权编辑。
- 先建组并加人：
sudo groupadd tempusers && sudo usermod -aG tempusers user1 user2 - 设目录属组：
sudo chgrp tempusers /data/temp - 启用 SGID + 粘滞位：
sudo chmod 2775 /data/temp（2=SGID，775=属主/组可读写执行，other 只读执行） - 验证：
ls -ld /data/temp应显示drwxrwsr-x（小写s表示 SGID 生效），再加+t后末位变t，即drwxrwsr-t
真正容易被忽略的点是：粘滞位和 SGID 都依赖目录的执行权限，而执行权又和 shell 的路径解析、find 或 rsync 等工具的行为强相关；一旦出现 Permission denied 报错，先看 ls -ld 末位是 t 还是 T，再检查 o+x 是否真存在。
