6

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

Improve this question
3
  • What filesystem are you using for $HOME? (Run mount | grep $(df -h "$HOME | awk 'NR>1 {print $1}') if you're not sure.) Commented Apr 15, 2015 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) Commented Apr 15, 2015 at 17:53
  • @MicahManary put additional information in the question. Commented Apr 15, 2015 at 18:37

3 Answers 3

Reset to default
2

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.

Improve this answer
1
  • 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. Commented Apr 16, 2015 at 23:46
1

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.

Improve this answer
-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.

Improve this answer
1
  • 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---. Commented Apr 15, 2015 at 21:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.