权限被拒绝尝试附加到已安装目录中的文件

Posted 2023-03-14

【中文标题】权限被拒绝尝试附加到已安装目录中的文件

【英文标题】：Permission denied trying to append to a file in a mounted directory

【发布时间】：2017-05-16 05:23:32

【问题描述】：

我无法理解为什么我无法附加到 python3 (3.2.3) 中的文件。我在共享文件夹中创建这些文件，但无法附加到它们。我的主文件夹中的文件没有问题。共享文件夹权限为：

drwxrwxrwx  2 nobody   share       65536 2017-01-01 22:16 Pictures

我在拥有所有权限的“共享”组中：

groups alex
share www-data

我可以创建文件：

>>> testFile=open ('VID_2.mp4', 'wb')
>>> testFile.close()

但我不能附加到它：

>>> testFile=open ('VID_2.mp4', 'ab')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied: 'VID_2.mp4'

我检查了文件权限，据我了解，我应该能够附加到该文件：

ls -l
-rw-rw-rw- 1 alex share 0 2017-01-01 22:40 VID_2.mp4    

所以我很困惑为什么拒绝追加权限，以及允许追加需要什么权限。

更新： 似乎问题不在于 python 脚本，因为如果我使用echo，我会得到相同的权限错误：

touch myfile.txt
echo 1 > myfile.txt
echo 2 >> myfile.txt
-bash: myfile.txt Permission denied
ls -l myfile.txt
-rw-rw-rw- 1 alex share 2 2017-01-03 09:44 myfile.txt

更新 2：

这些文件夹在常规装载 (/DataVolume) 下：

/dev/sda4 on /DataVolume type ext4 (rw,noatime,nodiratime)
/DataVolume/cache on /CacheVolume type none (rw,bind)
/DataVolume/shares on /shares type none (rw,bind)
/DataVolume/shares on /nfs type none (rw,bind)

cat /proc/mounts
/dev/sda4 /DataVolume ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/sda4 /CacheVolume ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/sda4 /shares ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/sda4 /nfs ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0

我可以追加到/DataVolume/home/alex 中的文件，但不能追加到/DataVolume/shares 下的文件：

ls -l /DataVolume/
drwxrwxr-x  4 root root      65536 2013-11-14 21:15 home
drwxrwxr-x  7 root share     65536 2017-01-04 10:16 shares
ls -l /DataVolume/home/
drwxr-xr-x 7 alex   share 65536 2017-01-01 22:24 alex
ls -l /DataVolume/home/alex
-rw-rw-rw- 1 alex share     4 2017-01-04 10:20 test.txt
ls -l /DataVolume/shares/
drwxrwxrw-  2 alex   share 65536 2017-01-04 10:23 test

编辑：我不再拥有有问题的设备，因此我将无法再验证任何建议。

【问题讨论】：

写入权限允许附加到文件，因此您的 Python 脚本有问题（在问题中未显示的部分）。您是否尝试过在纯 shell 中测试权限？例如。 cd Pictures; touch file; echo 1 > file。顺便说一句，从脚本中看不到您正在打开Pictures 目录中的文件。

echo 1 > file 有效，但随后的 echo 1 >> file 无效（相同的权限错误）。我会更新我的答案。

您的图片文件夹是在本地文件系统上还是从某个地方安装的？如果在特定目录上有 mount 或 bindfs，它可能会弄乱“标准”unix 权限。

如果你 cd /tmp 并在那里执行你的 shell 测试（触摸、回声等）会发生什么？它会产生相同的结果，还是 echo 2 >> myfile.txt 现在可以工作？

在/tmp 上的测试没有问题。图片文件夹是常规 ext4 安装的子文件夹。 /dev/sda4 on /DataVolume type ext4 (rw,noatime,nodiratime)。其中一位父母也绑定到其他文件夹，但我没有使用那些。我觉得这个坐骑有点东西。我在它下面创建了一个新文件夹（归我所有，但我仍然无法追加）

【参考方案1】：

检查您的umask 设置，文件在创建后没有获得可执行权限。 umask 002 应该解决这个问题。

-rw-rw-rw- 1 alex share 2 2017-01-03 09:44 myfile.txt

【讨论】：

据我所知，追加/写入文件不需要可执行权限。 umask 002 也不意味着 --wx-wx--x 吗？

@Mahaalaxmi：OP 显示 perms 对创建的文件是打开的，所以不是 umask。所描述的'umask 002'也是-rw-rw-r--。 @ Alecz，不，unsk 002 表示-rw-rw-r--。 umask 是 /mask/，与 chmod 相对的二进制。 umask 002 从正常的 666 perms 中屏蔽掉 002 位，使其成为 664。OP，这是 MacOSX 吗？听起来像是奇怪的挂载标志（篡夺了正常的 unix 权限），或者可能是在模拟 unix 权限的地方挂载了非 unix 文件系统（Windows？），和/或 ACL 权限有效（参见'ls -la@'， @ 显示 ACL) 还要检查父目录上的粘滞/setuid/gid 位。

@erco，该设备是 Western Digital My Book Live，它在 PowerPC 架构上运行 Debian。正如您从我的帖子中看到的那样，这是 /dev/sda4 到 /DataVolume 作为 ext4 的常规挂载。