Can I port user permissions across computers for an ext4 external hard drive?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
16
down vote

favorite
6












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.










share|improve this question























  • 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














up vote
16
down vote

favorite
6












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.










share|improve this question























  • 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












up vote
16
down vote

favorite
6









up vote
16
down vote

favorite
6






6





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.










share|improve this question















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.







permissions ext4 external-hdd






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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
















  • 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










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



  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.






share|improve this answer
















  • 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

















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''.







share|improve this answer






















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


















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?






share|improve this answer





























    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/





    share|improve this answer






















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      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






























      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



      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.






      share|improve this answer
















      • 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














      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



      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.






      share|improve this answer
















      • 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












      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



      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.






      share|improve this answer












      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.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      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












      • 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












      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''.







      share|improve this answer






















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















      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''.







      share|improve this answer






















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













      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''.







      share|improve this answer














      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''.








      share|improve this answer














      share|improve this answer



      share|improve this answer








      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

















      • 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











      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?






      share|improve this answer


























        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?






        share|improve this answer
























          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?






          share|improve this answer














          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?







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 13 '17 at 12:37









          Community♦

          1




          1










          answered Apr 23 '14 at 23:11









          derobert

          69.6k8151207




          69.6k8151207




















              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/





              share|improve this answer


























                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/





                share|improve this answer
























                  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/





                  share|improve this answer














                  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/






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Apr 13 '17 at 12:36









                  Community♦

                  1




                  1










                  answered Apr 1 '16 at 17:09









                  gavenkoa

                  24939




                  24939



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      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













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Bahrain

                      Postfix configuration issue with fips on centos 7; mailgun relay