Hopefully an easy question, but I'm having trouble finding any similar questions.

In my Ubuntu system I have an external hard drive. When I make a file in this external drive, I noticed I can't then open the file. After some digging I noticed this was because the directories created in the hard drive are created with permission 664, which is not very useful for directories. (Files are created with 664 also, which to me makes no sense). I've checked and in the main file system (not within the external drive) the creation of files follows the umask value of 0022 like it should. Directories come into creation as 755, and files as 644.

My question is: why is my external hard drive ignoring my umask? I'm making the files locally, there's nothing fancy going on here, so why would my default permissions in an external drive differ from my system and where can I change that?

I can manually change the permissions to what they need to be, but that is very tedious. Let me know if more information is needed, I don't really know what needs to be known.

EDITS: Replicating the error: Inside Computer itself, umask works correctly.

tnevins@mixing:Music$ umask
tnevins@mixing:Music$ mkdir mydir
tnevins@mixing:Music$ touch myfile
tnevins@mixing:Music$ ls -l
total 4
drwxr-xr-x 2 tnevins mixinglab 4096 May 10 11:23 mydir
-rw-r--r-- 1 tnevins mixinglab    0 May 10 11:23 myfile

Inside the drive /tank/planktonPool it does not.

tnevins@mixing:planktonPool$ umask
tnevins@mixing:planktonPool$ mkdir mydir
tnevins@mixing:planktonPool$ touch myfile
tnevins@mixing:planktonPool$ ls -l
drw-rw-r--+  2 tnevins mixinglab  4096 May 10 11:27 mydir
-rw-rw-r--   1 tnevins mixinglab     0 May 10 11:27 myfile


UUID=f1a76953-ece5-4559-8436-54bdd86d7fee /media/tank ext4 nofail,defaults 0 2

sudo lsblk -f

NAME   FSTYPE LABEL        UUID                                 MOUNTPOINT
└─sda1 ext4                a1e54134-bc37-4f85-9f61-65311b75c573 /
└─sdb1 ext4   mixingBackup 9ccbbee0-167e-4b19-bcf8-b2648a7dd40c /media/mixingBac
└─sdc1 ntfs   vault        220EA82D219FBF1D                     /media/vault
└─sdd1 ext4   tank         f1a76953-ece5-4559-8436-54bdd86d7fee /media/tank

Ah, so based on this command it looks like the "tank" drive is the sdd1 drive. It is the one I'm currently asking about.

sudo lsblk -m

sda      1.8T root  disk  brw-rw----
└─sda1   1.8T root  disk  brw-rw----
sdb    931.5G root  disk  brw-rw----
└─sdb1 931.5G root  disk  brw-rw----
sdc     10.9T root  disk  brw-rw----
└─sdc1  10.9T root  disk  brw-rw----
sdd      8.2T root  disk  brw-rw----
└─sdd1   8.2T root  disk  brw-rw----

sudo parted -ls

Model: ATA WDC WD2003FZEX-0 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  2000GB  2000GB  primary  ext4         boot

Model: Seagate Backup+ BK (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  1000GB  1000GB  primary  ext4

Model: TT H/W R AID5 (scsi)
Disk /dev/sdc: 12.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  12.0TB  12.0TB  ntfs               msftdata

Model: HzW RAID 5 (scsi)
Disk /dev/sdd: 9002GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  9002GB  9002GB  ext4               msftdata


Filesystem                   1K-blocks        Used  Available Use% Mounted on
udev                          32931096           0   32931096   0% /dev
tmpfs                          6591648        3428    6588220   1% /run
/dev/sda1                   1921802432   213108624 1611001752  12% /
tmpfs                         32958224       46184   32912040   1% /dev/shm
tmpfs                             5120           4       5116   1% /run/lock
tmpfs                         32958224           0   32958224   0% /sys/fs/cgroup
/dev/sdc1                  11720883180 10724315468  996567712  92% /media/vault
/dev/sdd1                   8721245008  8136336948  145359752  99% /media/tank
/dev/sdb1                    961302556   961286176          0 100% /media/mixingBackup
tmpfs                          6591644          20    6591624   1% /run/user/127 11627446496  8377352688 2664031680  76% /media/cage
tmpfs                          6591644           0    6591644   0% /run/user/1001
tmpfs                          6591644       10144    6581500   1% /run/user/1003
tmpfs                          6591644           0    6591644   0% /run/user/1004

ls -ld /media/tank/

drwxrwxrwx 25 dhk mixinglab 4096 May 10 11:26 /media/tank/

ls -ld /media/tank/planktonPool/ (The folder I'm usually working in)

drwxrwxr-x+ 76 tnevins mixinglab 4096 May 10 11:27 /media/tank/planktonPool/
  • "external hard drive" please provide the /etc/fstab entry for this. Or the mount options used. And it better not be formatted as NTFS ;-)
    – Rinzwind
    Commented May 9, 2018 at 14:21
  • If you have a linux file system, the file permissions should match umask, but if you have a Microsoft file system (FAT or NTFS) in the external drive, linux will set the ownership and permissions when mounting the partition, and this will be inherited by all directories and files in the partition (unless you mount it with other mount options). See this link Mount a FAT32 partition in a USB stick with write permissions for everybody
    – sudodus
    Commented May 9, 2018 at 14:26
  • 3
    Rinzwind: /etc/fstab entry is UUID=f1a76953-ece5-4559-8436-54bdd86d7fee /media/tank ext4 nofail,defaults 0 2 So it is not formatted NTFS, but could that cause a problem, I notice I have another drive that has similar problems and it is NTFS. sudodus: I am not really sure which drive in the /dev folder corresponds to this drive. There are like 4 externals attached to this computer (its a laboratory computer and I didn't set it up, so I know little about its internal structure). Do you have a suggestion on where the sdxn of the drive would be written.
    – tnevins
    Commented May 9, 2018 at 15:05
  • 1
    Sorry, didn't see this question for a bit. Added the line, but I've noticed that actually the system follows umask on the initial level of /media/tank. Folders there have the right permissions, but not within the folder /media/tank/planktonPool, so I added the ls -ld for that too. That folder routinely has data copied to it from windows, how could that affect the results?
    – tnevins
    Commented May 15, 2018 at 13:37
  • 1
    So this problem is still happening and is still a massive issue for my work-flow. I find it hard to believe that nobody knows how to fix this or make progress on it, so help would still be appreciated. Recent developments: It is not the drive /media/tank/ that has the writing issue! Only the /tank/planktonpool/ folder has the issue. @sudodus the notion of me not owning it was a good one, unfortunately I do own the planktonpool folder. Is there any other possibilities?
    – tnevins
    Commented May 30, 2018 at 17:15

2 Answers 2


Fortunately you do own the planktonpool folder ;-) You (your user ID) have write permissions (as well as those in your group).

I see two options

  • Either you give write permissions to everybody, 'others' in chmod language

    sudo chmod o+w /media/tank/planktonPool/
  • or you add all user IDs that you expect will write to your group (or the group mixinglab).

    Add them at the end of the line starting with tnevins (after the colon, and if there are more than one user IDs, separate them with colons in the file /etc/group

    sudo nano /etc/group

Just one more thing: If some other users are writing, maybe the files (or directories) they write will get other permissions (without write permissions for other user IDs. In that case you will not be able to overwrite those files. Please check if that is the case (that some files in /media/tank/planktonPool/ lack write permissions, although you need to overwrite them).

  • sorry that's not what it was, but it is hardly your fault. I didn't mention that I am tnevins, so I do in fact own the planktonpool/ folder. I'm also in the mixinglab group so according to the ls -ld planktonPool/ line I definitely own the folder. Granted I don't own tank/, but that's not the directory with the issues. I would follow up on your last paragraph, but I have just solved the issue (answer below). To be fair we were all looking in the wrong place.
    – tnevins
    Commented May 31, 2018 at 13:30

So after a second round of digging I have found out what was wrong with the /planktonPool/ folder. If you notice the planktonPool folder has an access control list while the tank folder does not.

drwxrwxr-x+ 76 tnevins mixinglab 4096 May 10 11:27 /media/tank/planktonPool/
drwxrwxrwx 25 dhk mixinglab 4096 May 10 11:26 /media/tank/

I went investigating this and discovered the getfacl for the planktonPool folder was:

# file: planktonPool/
# owner: tnevins
# group: mixinglab

In other words: New folders created in planktonPool were given the default permissions, rather than going to the umask. Sorry I didn't know enough to provide the getfacl earlier, but that was where the problem was hiding. Since I didn't set up the computer, I don't always know all it's ins and outs. I eventually solved my issue by using the command:

setfacl -R -m default:u::rwx,default:g::rwx,default:o::r-x /media/tank/planktonPool/

Which I am certain is not the ideal it handles the biggest part of my problem: being able to make directories that I can't access.

If people still would like to help: I do note that when I create a new file, the permissions are still not matching umask. It is acting as though the umask is 0002 instead of 0022 but only within the planktonPool folder.

Thank you to all who helped, though it seems we were looking in the wrong place, and I'm sorry I didn't know enough to suggest otherwise.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .