Permission denied trying to append to a file in a mounted directory
Permission denied trying to append to a file in a mounted directory
I am having trouble understanding why I am unable to append to a file in python3 (3.2.3). I create these files in a shared folder but I am unable to append to them. There are no issues with files in my home folder. The shared folder permissions are:
drwxrwxrwx 2 nobody share 65536 2017-01-01 22:16 Pictures
I am in the 'share' group which has all the permissions:
groups alex
share www-data
I can create the file:
>>> testFile=open ('VID_2.mp4', 'wb')
>>> testFile.close()
But I cannot append to it:
>>> 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'
I checked the file permissions and, from my understanding, I should be able to append to that file:
ls -l
-rw-rw-rw- 1 alex share 0 2017-01-01 22:40 VID_2.mp4
So I am baffled as to why the permission to append is denied, and what permission would be required to allow the append.
UPDATE:
It seems the issue is not with the python script since I get the same permission error if I use echo:
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
UPDATE 2:
These folders are under a regular mount (/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
I can append to files in /DataVolume/home/alex but not to files under /DataVolume/shares:
/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
EDIT: I no longer have the device in question, so I won't be able to verify any of the suggestions anymore.
cd Pictures; touch file; echo 1 > file
Pictures
echo 1 > file works, but a subsequent echo 1 >> file does not (same permission error). I will update my answer.– Alecz
Jan 2 '17 at 19:43
echo 1 > file
echo 1 >> file
Is your Pictures folder on a local file system or is it mounted from somewhere? If there is a mount or bindfs on the particular directory, it can mess up "standard" unix permissions.
– Hannu
Jan 3 '17 at 17:02
What happens if you cd /tmp and execute your shell test (touch, echo etc) there? Does it produce the same result, or does echo 2 >> myfile.txt now work?
– Hannu
Jan 3 '17 at 17:08
testing on
/tmp has no issues. The Pictures folder is a sub-subfolder of a regular ext4 mount. /dev/sda4 on /DataVolume type ext4 (rw,noatime,nodiratime). One of the parents is also binded to other folders but I am not using those. I think there is something about this mount. I created a new folder under it (owned by me and I still cannot append)– Alecz
Jan 4 '17 at 15:06
/tmp
/dev/sda4 on /DataVolume type ext4 (rw,noatime,nodiratime)
1 Answer
1
Check your umask settings, the file is not getting executable permissions after creation. umask 002 should fix this.
umask
umask 002
-rw-rw-rw- 1 alex share 2 2017-01-03 09:44 myfile.txt
Executable permissions are not required to append/write to a file as far as I know. Also doesn't
umask 002 mean --wx-wx--x ?– Alecz
Sep 4 at 0:17
umask 002
@ Mahaalaxmi: OP shows perms are open for file created, so not umask. Also 'umask 002' as described would be -rw-rw-r--. @ Alecz, no, unask 002 means -rw-rw-r--. umask is a /mask/, binary opposite of chmod. umask 002 masks off the 002 bit from the normal 666 perms, making it 664. OP, is this MacOSX? Sounds like either weird mount flags (which usurp normal unix perms) or perhaps a non-unix file system is mounted (Windows?) where unix perms are emulated, and/or ACL permissions are in effect (see 'ls -la@', @ shows ACLs) Also check for sticky/setuid/gid bits on parent dirs.
– erco
Sep 18 at 15:47
@erco, the device was a Western Digital My Book Live which runs Debian on a PowerPC architecture. As you can see from my post, this was a regular mount of /dev/sda4 to /DataVolume as ext4.
– Alecz
Oct 30 at 23:57
Thanks for contributing an answer to Stack Overflow!
But avoid …
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
But avoid …
To learn more, see our tips on writing great answers.
Required, but never shown
Required, but never shown
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
The write permissions allow to append to a file, so there is something wrong with your Python script (in the parts that are not shown in the question). Have you tried to test the permissions in pure shell? E.g.
cd Pictures; touch file; echo 1 > file. By the way, it is not obvious from the script that you are opening the file inPicturesdirectory.– Ruslan Osmanov
Jan 2 '17 at 4:13