18

I have an external USB 3 disk drive (2TB capacity) that is most likely going to be moved from machine to machine. The disk has a GUID partition table and an ext4 partition. I am unable to write to the disk unless I elevate the process (sudo).

As of now I am thinking of trying one or both of the following and would like to know the cons of each -

  1. chmod 777 /mnt/externalDrive
  2. chown nobody:nogroup /mnt/externalDrive

If I give 777 permission and user1 (UID:1005) writes to it and I later move the disk to another computer where user7 is UID:1005, what happens? Does user7 become the owner of the file on that computer? It seems to me that I will periodically have to run chown -R nobody:nogroup /mnt/externalDrive on the disk.

Is any of what I am considering an obvious bad practice? The disk will most likely contain videos, music and pictures none of it need to be protected like some financial data.

2
  • I am not sure if I follow you. Did you try setting the permissions in the external drive?
    – Ramesh
    Apr 23, 2014 at 23:01
  • 1
    Yes. Is that a good thing?
    – Lord Loh.
    Apr 24, 2014 at 0:03

4 Answers 4

Reset to default
22

That's the problem with multi-user systems, especially if you have more than one of them. ;) There's no really nice way to do what you want. Approaches coming to mind would be

  • having the same UID for your account on every machine you're using your external drive (actually not feasible, since most probably not all of the machines are under your control)
  • using a file-system unaware of owner/group conecpt (FAT or NTFS coming to mind, but… aaah, no)

The most effective approach would be coming back to common practices. On most (at least) Linux systems, there exist some groups which have usually common GIDs. On example would be users, which has GID 100 on most Linux distros. If you could manage to have your respective user account in this group, you could

  1. make all files and directories on your drive owned by this group
  2. somehow manage to have appropriate group-permissions on those files and directories
  3. somehow manage to have new files created with appropriate group-ownership resp. permissions.

First and second point are easy to accomplish (chown, chmod). Third point get's a bit trickier.

The "group-ownership" part is relatively easy: You could set the SGID bit on all directories on the drive. The SGID bit applied to directories tells the kernel to behave in a BSDish way: BSD makes every file/directory created under a specific directory group-owned not by the primary group of the process creating the file/directory (as Linux does), but by the owner of the parent-directory.

The permission bit is a bit hard. Permissions of newly created files/directories are (amongst others) influenced by the umask, a bit-mask telling which bits not to set if not explicitly stated. A common umask value for example is 022, meaning that the write-bits for »group« and »others« shouldn't usually be set. You could change your umask to 002, telling you don't want the write-permissions to be cleared for the group but the downside is that you can't set this value directory-based and you usually don't want to have write-permissions for your primary group set for every file you create.

This could be solved using ACLs: In an ACL you can set a mask and a default permission set, which applies to all files and directories created inside a directory with this ACL set. So one possible solution of your problem would be

  • making sure you are a member of a common group on all systems you want to use your external drive on
  • make all files and directories on your drive owned by this group and set the SGID bit on all directories
  • change the ACL of all directories to include a mask and default permissions that tell the kernel to create every new file/directory with write-permissions set for the group.

See setfacl(1), and acl(5) for more details.

1
12

There's another similar question and bindfs is suggested there:

mkdir /home/$user/sda1
bindfs -u $user -g $group /mnt/sda1 /home/$user/sda1

OSX users suggest noowners mount option described like this:

Ignore the ownership field for the entire volume. This causes all objects to appear as owned by user ID 99 and group ID 99. User ID 99 is interpreted as the current effective user ID, while group ID 99 is used directly and translates to ``unknown''.

1
  • bindfs is pretty slow. Probably because it's a FUSE filesystem.
    – Navin
    Jul 27, 2017 at 1:59
4

The owner and group of a file are stored as numbers. So the file will be owned by uid=1005, regardless of which user (or none at all) that is on the system its connected to.

Changing the user/group to nobody won't fix your problem. Then only the nobody user (or members of the nobody group) would be allowed to access the files.

Unfortunately, I don't think there is a way to disable permission checks on ext4. See, for example, Is it possible to disable file permissions on a ext3 or ext4 file-system?

2

Andreas Wiese say that if you have common group id across all hosts you may solve your issue with setgid bit and ACL

I ask question Predefined group ids across Linux distros?

After own research found that such group exist across all touched distros: sys group share id 3 on Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.

With this:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chmod -R g+s /mnt/data/dir
$ sudo setfacl -R -m g:sys:rwx /mnt/data/dir
$ sudo setfacl -R -d -m g:sys:rwx /mnt/data/dir

and flavor of this:

$ sudo adduser user sys

you user be able to read/write any file on /dir.

Most job may do setgid bit but unfortunately you usually have little control on umask. So ACL is used to provide complete solution.

See also:

You must log in to answer this question.

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