Arquivos criados na unidade não correspondem a umask

Question

Espero que seja uma pergunta fácil, mas estou com dificuldades para encontrar perguntas semelhantes.

No meu sistema Ubuntu eu tenho um disco rígido externo. Quando eu faço um arquivo nesta unidade externa, percebo que não consigo abrir o arquivo. Depois de algumas escavações, notei que isso ocorreu porque os diretórios criados no disco rígido são criados com a permissão 664, o que não é muito útil para diretórios. (Arquivos são criados com 664 também, o que para mim não faz sentido). Eu verifiquei e no sistema de arquivos principal (não dentro da unidade externa) a criação de arquivos segue o valor de umask de 0022 como deveria. Os diretórios entram em criação como 755 e arquivos como 644.

Minha pergunta é: por que meu disco rígido externo está ignorando minha umask? Eu estou fazendo os arquivos localmente, não há nada extravagante acontecendo aqui, então por que minhas permissões padrão em uma unidade externa diferem do meu sistema e onde posso mudar isso?

Eu posso alterar manualmente as permissões para o que elas precisam ser, mas isso é muito entediante. Deixe-me saber se mais informações são necessárias, eu realmente não sei o que precisa ser conhecido.

EDITES: Replicando o erro: Dentro do próprio computador, o umask funciona corretamente.

tnevins@mixing:Music$ umask
0022
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

Dentro do drive / tanque / plânctonPool não.

tnevins@mixing:planktonPool$ umask
0022
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

/ etc / fstab

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

sudo lsblk -f

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

Ah, então, com base nesse comando, parece que a unidade "tank" é a unidade sdd1. É o que estou perguntando atualmente.

sudo lsblk -m

NAME     SIZE OWNER GROUP MODE
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

df

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
128.151.161.22:/media/cage 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 / (A pasta na qual normalmente estou trabalhando)

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

    

Answer 1

Então, depois de uma segunda rodada de escavações, descobri o que havia de errado com a pasta / planktonPool /. Se você perceber que a pasta planktonPool tem uma lista de controle de acesso enquanto a pasta do tanque não.

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

Eu fui investigar isso e descobri que o getfacl da pasta planktonPool era:

# file: planktonPool/
# owner: tnevins
# group: mixinglab
user::rwx
group::rwx
other::r-x
default:user::rw-
default:group::rw-
default:other::r--

Em outras palavras: Novas pastas criadas no planktonPool receberam as permissões padrão, em vez de irem para o umask. Desculpe eu não sabia o suficiente para fornecer o getfacl mais cedo, mas era aí que o problema estava se escondendo. Desde que eu não configurei o computador, eu nem sempre sei tudo que é ins e outs. Eu finalmente resolvi meu problema usando o comando:

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

O que eu tenho certeza não é o ideal, ele lida com a maior parte do meu problema: ser capaz de criar diretórios que eu não posso acessar.

Se as pessoas ainda quiserem ajudar: eu noto que quando eu crio um novo arquivo, as permissões ainda não estão correspondendo a umask. Ele está agindo como se o umask fosse 0002 em vez de 0022, mas somente dentro da pasta planktonPool.

Obrigado a todos que ajudaram, embora pareça que estávamos procurando no lugar errado, e me desculpe por não saber o suficiente para sugerir o contrário.

    

Answer 2

Felizmente você possui a pasta planktonpool ;-) Você (seu ID de usuário) tem permissões de gravação (assim como as do seu grupo).

vejo duas opções

• Você concede permissões de gravação para todos, "outros" em chmod language

  sudo chmod o+w /media/tank/planktonPool/
  

• ou adicione todos os IDs de usuário que você espera que gravem no seu grupo (ou no grupo mixinglab ).

  Adicione-os ao final da linha, começando com tnevins (depois dos dois pontos, e se houver mais de um ID de usuário, separe-os com dois-pontos no arquivo /etc/group

  sudo nano /etc/group
  

Apenas mais uma coisa: Se alguns outros usuários estiverem escrevendo, talvez os arquivos (ou diretórios) que eles gravam receberão outras permissões (sem permissões de gravação para outros IDs de usuário. Nesse caso você não Para substituir esses arquivos, verifique se esse é o caso (que alguns arquivos em /media/tank/planktonPool/ não possuem permissões de gravação, embora seja necessário sobrescrevê-los).