5

Whenever I create new directories in my home (or its subdirectories) they do not have write permission, even though umask is set correctly. Files I make DO have write permission.

[mmanary@seqap33 ~]$ umask
0002
[mmanary@seqap33 ~]$ mkdir testDir
[mmanary@seqap33 ~]$ touch testFile
[mmanary@seqap33 ~]$ ls -l
dr-xr-x--- 2 mmanary mmanary  0 Apr 15 10:25 testDir
-rw-rw-r-- 1 mmanary mmanary  0 Apr 15 10:26 testFile

If I switch to a shared group storage directory, then new directories DO have write permission. I can switch them with chmod easily, BUT when using tar, the new directory cannot be written in to so the tar fails with "Permission Denied". Any help is appreciated.

Edit: I have read other suggested questions, but not seem to apply directly because they involve more complicated cases (other users involved). In case this helps:

[mmanary@seqap33 ~]$ getfacl .
# file: .
# owner: mmanary
# group: mmanary
user::rwx
group::r-x
other::---

Edit2: On advice from comments, my filesystem is NFS

  • What filesystem are you using for $HOME? (Run mount | grep $(df -h "$HOME | awk 'NR>1 {print $1}') if you're not sure.) – roaima Apr 15 '15 at 17:43
  • Well that exact command doesn't work. I get two lines of output from awk (the second line being "1.5P"). If I just search for the first line (i.e. second from df) I get isilon12:/ifs/data/rd/home/mmanary on /home/mmanary type nfs (rw,addr=XXX.XX.XX.XXX) – Micah Manary Apr 15 '15 at 17:53
  • @MicahManary put additional information in the question. – Faheem Mitha Apr 15 '15 at 18:37
1

Talked to the infrastructure people, and the answer is that there are extended ACLs in place that act differently based on location, and that they were erroneously set.

  • Indeed ACLs are the most obvious way to set up a directory in which permissions of new files don't follow the umask of the creating process. – Gilles Apr 16 '15 at 23:46
0

The only time I have seen this kind of scenario is when the NFS share is exported from a Windows server running NFS for Windows services. The POSIX attributes demanded by the Unix/Linux world aren't mapped cleanly onto the NTFS attributes and the result is that permissions display one thing and (sometimes) act as another.

In our particular situation we spent a couple of weeks trying to resolve the situation and eventually erased the Windows system and installed a Linux-based system on the hardware.

-1

If the sticky bit chmod +s is set on the folder, the umask is overridden with the attributes of the folder owner. that is why you may be seeing inconsistent results between folders.

  • 1
    That's not the problem here. The umask of 0002 means the directory should normally be created drwxrwxr-x, but it's got dr-xr-x---. – Mikel Apr 15 '15 at 21:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.