sharing ext. disk among mac, linux, windows

Discussion in 'Mac Basics and Help' started by Z=80, Jul 7, 2008.

  1. Z=80 macrumors newbie

    Jul 7, 2008

    I have a portable USB disk that will be used with 3 machines, one each of Mac (10.5), linux (CentOS), and windows (XP). In particular, it is absolutely essential that on the mac and the linux box the files be shareable without read/write/permissions problems. Is the answer to have 2 partitions, one HFS+ (non-journaled?) and one FAT32? What about GPT vs Master Boot Record? Any other thing to watch out for in the set up?

    Thanks. All information appreciated.
  2. Z=80 thread starter macrumors newbie

    Jul 7, 2008
    sharing ext disk -- update with a solution

    Putting this solution out there in case other people face a similar problem. To recap, the issue was to use an external Seagate FreeAgent Go portable USB disk with Leopard (10.5.4), CentOS 5, and Windows, while retaining the possibility of file permissions. In the end, what worked was this: the external disk was partitioned into two volumes, one FAT32 and the other HFS+. The FAT32 doesn't present any problems. However, to get the HFS+ to work correctly on OS X and Linux:
    -- the volume had to be case-insensitive, non-journaled, and owner disabled.
    -- turns out when you disable ownership on the Mac side, OS X assigns uid and gid 99 to everything on the disk. OS X interprets this to mean "use effective uid and gid of the user mounting the disk", so it works fine on the Mac. In CentOS, uid and gid=99 translated into the user & group nobody, and permission 664, which meant that I could not access the files. This was solved by chown-ing, and has to be done whenever a file is created on the Mac. Files created in CentOS do not have problems in OS X.
    -- finally, Seagate FreeAgent drives don't work well with Linux because of their power save mode. The drive goes to sleep and gets unmounted. The next time you try to access it the file system mounts read-only. The workaround is to use sdparm to unset the STANDBY flag, as described here If it does end up in read-only mode, it can be fixed by running fsck_hfs -p, i.e. in preen mode. Running full fsck_hfs causes a segmentation fault.

    Not elegant, but eveything works now.

Share This Page