Can I port user permissions across computers for an ext4 external hard drive?
Clash Royale CLAN TAG#URR8PPP
up vote
16
down vote
favorite
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 -
chmod 777 /mnt/externalDrive
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.
permissions ext4 external-hdd
add a comment |Â
up vote
16
down vote
favorite
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 -
chmod 777 /mnt/externalDrive
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.
permissions ext4 external-hdd
I am not sure if I follow you. Did you try setting the permissions in the external drive?
â Ramesh
Apr 23 '14 at 23:01
1
Yes. Is that a good thing?
â Lord Loh.
Apr 24 '14 at 0:03
add a comment |Â
up vote
16
down vote
favorite
up vote
16
down vote
favorite
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 -
chmod 777 /mnt/externalDrive
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.
permissions ext4 external-hdd
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 -
chmod 777 /mnt/externalDrive
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.
permissions ext4 external-hdd
permissions ext4 external-hdd
edited Sep 22 at 21:14
asked Apr 23 '14 at 22:50
Lord Loh.
72141128
72141128
I am not sure if I follow you. Did you try setting the permissions in the external drive?
â Ramesh
Apr 23 '14 at 23:01
1
Yes. Is that a good thing?
â Lord Loh.
Apr 24 '14 at 0:03
add a comment |Â
I am not sure if I follow you. Did you try setting the permissions in the external drive?
â Ramesh
Apr 23 '14 at 23:01
1
Yes. Is that a good thing?
â Lord Loh.
Apr 24 '14 at 0:03
I am not sure if I follow you. Did you try setting the permissions in the external drive?
â Ramesh
Apr 23 '14 at 23:01
I am not sure if I follow you. Did you try setting the permissions in the external drive?
â Ramesh
Apr 23 '14 at 23:01
1
1
Yes. Is that a good thing?
â Lord Loh.
Apr 24 '14 at 0:03
Yes. Is that a good thing?
â Lord Loh.
Apr 24 '14 at 0:03
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
18
down vote
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
- make all files and directories on your drive owned by this group
- somehow manage to have appropriate group-permissions on those files and directories
- 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
There was a patch floating around for his and gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html, but I do not think it has come through...
â Rmano
Apr 24 '14 at 3:22
add a comment |Â
up vote
10
down vote
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''.
bindfs is pretty slow. Probably because it's a FUSE filesystem.
â Navin
Jul 27 '17 at 1:59
add a comment |Â
up vote
4
down vote
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?
add a comment |Â
up vote
2
down vote
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:
- https://askubuntu.com/questions/12009/solving-permission-problems-when-using-external-ext4-hard-disk-with-multiple-lin/
- https://askubuntu.com/questions/252361/how-could-i-mount-an-ext4-partition-and-have-write-permission/
- https://serverfault.com/questions/306344/sharing-an-ext3-ext4-partition-on-external-drive/
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
18
down vote
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
- make all files and directories on your drive owned by this group
- somehow manage to have appropriate group-permissions on those files and directories
- 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
There was a patch floating around for his and gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html, but I do not think it has come through...
â Rmano
Apr 24 '14 at 3:22
add a comment |Â
up vote
18
down vote
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
- make all files and directories on your drive owned by this group
- somehow manage to have appropriate group-permissions on those files and directories
- 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
There was a patch floating around for his and gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html, but I do not think it has come through...
â Rmano
Apr 24 '14 at 3:22
add a comment |Â
up vote
18
down vote
up vote
18
down vote
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
- make all files and directories on your drive owned by this group
- somehow manage to have appropriate group-permissions on those files and directories
- 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.
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
- make all files and directories on your drive owned by this group
- somehow manage to have appropriate group-permissions on those files and directories
- 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.
answered Apr 23 '14 at 23:08
Andreas Wiese
7,4902132
7,4902132
1
There was a patch floating around for his and gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html, but I do not think it has come through...
â Rmano
Apr 24 '14 at 3:22
add a comment |Â
1
There was a patch floating around for his and gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html, but I do not think it has come through...
â Rmano
Apr 24 '14 at 3:22
1
1
There was a patch floating around for his and gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html, but I do not think it has come through...
â Rmano
Apr 24 '14 at 3:22
There was a patch floating around for his and gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html, but I do not think it has come through...
â Rmano
Apr 24 '14 at 3:22
add a comment |Â
up vote
10
down vote
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''.
bindfs is pretty slow. Probably because it's a FUSE filesystem.
â Navin
Jul 27 '17 at 1:59
add a comment |Â
up vote
10
down vote
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''.
bindfs is pretty slow. Probably because it's a FUSE filesystem.
â Navin
Jul 27 '17 at 1:59
add a comment |Â
up vote
10
down vote
up vote
10
down vote
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''.
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''.
edited Apr 13 '17 at 12:36
Communityâ¦
1
1
answered Oct 12 '14 at 15:24
Michael Shigorin
75259
75259
bindfs is pretty slow. Probably because it's a FUSE filesystem.
â Navin
Jul 27 '17 at 1:59
add a comment |Â
bindfs is pretty slow. Probably because it's a FUSE filesystem.
â Navin
Jul 27 '17 at 1:59
bindfs is pretty slow. Probably because it's a FUSE filesystem.
â Navin
Jul 27 '17 at 1:59
bindfs is pretty slow. Probably because it's a FUSE filesystem.
â Navin
Jul 27 '17 at 1:59
add a comment |Â
up vote
4
down vote
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?
add a comment |Â
up vote
4
down vote
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?
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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?
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?
edited Apr 13 '17 at 12:37
Communityâ¦
1
1
answered Apr 23 '14 at 23:11
derobert
69.6k8151207
69.6k8151207
add a comment |Â
add a comment |Â
up vote
2
down vote
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:
- https://askubuntu.com/questions/12009/solving-permission-problems-when-using-external-ext4-hard-disk-with-multiple-lin/
- https://askubuntu.com/questions/252361/how-could-i-mount-an-ext4-partition-and-have-write-permission/
- https://serverfault.com/questions/306344/sharing-an-ext3-ext4-partition-on-external-drive/
add a comment |Â
up vote
2
down vote
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:
- https://askubuntu.com/questions/12009/solving-permission-problems-when-using-external-ext4-hard-disk-with-multiple-lin/
- https://askubuntu.com/questions/252361/how-could-i-mount-an-ext4-partition-and-have-write-permission/
- https://serverfault.com/questions/306344/sharing-an-ext3-ext4-partition-on-external-drive/
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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:
- https://askubuntu.com/questions/12009/solving-permission-problems-when-using-external-ext4-hard-disk-with-multiple-lin/
- https://askubuntu.com/questions/252361/how-could-i-mount-an-ext4-partition-and-have-write-permission/
- https://serverfault.com/questions/306344/sharing-an-ext3-ext4-partition-on-external-drive/
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:
- https://askubuntu.com/questions/12009/solving-permission-problems-when-using-external-ext4-hard-disk-with-multiple-lin/
- https://askubuntu.com/questions/252361/how-could-i-mount-an-ext4-partition-and-have-write-permission/
- https://serverfault.com/questions/306344/sharing-an-ext3-ext4-partition-on-external-drive/
edited Apr 13 '17 at 12:36
Communityâ¦
1
1
answered Apr 1 '16 at 17:09
gavenkoa
24939
24939
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f126213%2fcan-i-port-user-permissions-across-computers-for-an-ext4-external-hard-drive%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I am not sure if I follow you. Did you try setting the permissions in the external drive?
â Ramesh
Apr 23 '14 at 23:01
1
Yes. Is that a good thing?
â Lord Loh.
Apr 24 '14 at 0:03