|
JFS partities en "logische" volumes Een JFS partitie voor Linux en OS/2 aanmaken Bestandsrechten onder Linux en OS/2
|
|
Steeds is het belangrijk om onderscheid te maken tussen partities met al dan niet JFS erop en logische LVM volumes. Alle partities worden door een FDISK aangemaakt, maar om die partities onder OS/2 zichtbaar te maken hebt u de hulp van de Logische Volume Manager en passende stuurbestanden nodig. Maar omdat onder OS/2 4.5 (eCS) zowel het partitioneren als logische volumebeheer met het LVM programma doet, ontstaat er verwarring. Temeer omdat de naamgeving van LVM uiterst verwarrend is.
Bij haar FDISK functie maakt LVM een kunstmatig onderscheid tussen de voor JFS bestemde partities (LVM volume) en andere partities (compatibility volume).
Create a new volume Create a volume that does not need to be bootable
En daarna krijgt u de keus tussen :
Create a compatibility volume Create an LVM volume
Bij het partitioneren worden de begin- en eindsector van een JFS partitie (partitietype 35) in de master boot sector van de vaste schijf vastgelegd. Een JFS partitie is dan ook niet meer dan een met LVM of een Linux FDISK aangemaakt continu deel van de vaste schijf. U kunt van een FAT partitie een nog niet geformatteerde JFS partitie maken door het partitietype van 6 in 35 te wijzigen en hem daarna onder Linux formatteren. Maar onder OS/2 moet u kiezen voor :
Create an LVM volume
Nadat u met LVM aan een type 35 partitie een stationsnaam toegekend heeft, kunt u de partitie met het JFS bestandssysteem formatteren. Het uit DOS tijden stammende formatterings programma van OS/2 wil een schijfletter zien: format [station:] /FS:JFS /BS:4096. Onder Linux gaat het ook, maar dan met de /dev/hd[letter][nummer] aanduiding van het virtuele bestandssysteem. Daarna hebt u een geformatteerde JFS partitie, die u zowel onder Linux als OS/2 kunt benaderen. Onder Linux moet u de partitie nog op het bestandssysteem mounten (fstab, mount opdacht); voor OS/2 moet u een onder Linux geformatteerde partitie met LVM een stationsaanduiding geven.
Create an LVM volume Y: (selecteer stationsaanduiding) Enter a name for the volume: backup Choose a disk for the volume. Press F6 to complete creation of the volume. 1 hda 117239 0 0 (selecteer schijf) Use existing partition P12 - 20002.8 MiB 20002 (kies partitie) Enter a name for the partition: P12 - 20002.8 MiB F6=finish Esc=back F1=help
Bevestig met F6
--------------------------------------------------------------------------- backup Y: LVM None 20000 --------------------------------------------------------------------------- Disk Partition Size (MB) Disk Name P12 - 20002.8 MiB 20000 hda --------------------------------------------------------------------------- F1=help F3=exit F5=Physical View Enter=Options Tab=Window ---------------------------------------------------------------------------
Bevestig met met F3
Return to the program Discard the changes and exit Save the changes and exit
En opslaan met: Save the changes and exit.
In dit geval hebben we een als JFS geformatteerde partitie die onder OS/ 2 tevens een LVM volume met stationsaanduiding is. Dergelijke partities zijn met recente stuurbestanden goed onder OS/2 en Linux te benaderen, zolang u tijdens het formatteren maar de door Linux ondersteunde blokgrootte van 4 KB gebruikt (format D: /FS:JFS /BS:4096 of de ?BS optie weglaten).
Toch gaat het niet altijd zo gemakkelijk als hier lijkt. Ik ben met twee systemen mee aan de slag gegaan. In beide gevallen ging het om SuSE Linux 8.2 en eCS 1.1.
Tijdens de installatie van Linux bleek het partioneringsprogramma GNU Parted van SuSE Linux 8.2 niet met eCS's 1.1 LVM volumes te kunnen omgaan. Doordat dit open source partioneringsprogramma het wel van te voren aangaf, bespaarde het me veel ellende. Maar andere partitioneringsprogramma's kunnen overmoedig zijn!
Ook de Linux fdisk had moeite met LVM's partities. Zo kon hij geen vrije ruimte zien nadat ik een LVM volume gewist had.
Om te beginnen heb ik OS/2 (eCS) geïnstalleerd. De door mijn werk afgedankte 1000 MHZ Compaq Deskpro P3 was vooral bedoeld als spelletjes PC voor de kinderen, vandaar dat ik naast OS/2 ook Windows 95 en Linux wilde installeren. Windows 95 voor Windows spelletje en Linux en OS/2 voor de internettoegang. OS/2 werd als eerste geïnstalleerd. Hiermee werd ook gepartitioneerd.
Voor de Linux was de eerste opzet als volgt:
/dev/hda10 /boot (EXT3) /dev/hda14 /home (JFS) /dev/hda15 swap /dev/hda16 / (JFS)
Hier kon PARTED echter niet mee overweg. De door OS/2 aangemaakte JFS partities werden niet gemount en Linux had moeite met de door OS/2 aanmaakte JFS partitie aan het eind van de schijf. Maar de zich in de partitietabel verslikkende PARTED vertikte het om partities aan te passen of te te wissen.
Daarna kwam ik tot deze oplossing:
/dev/hda10 /boot (EXT3) /dev/hda14 / (JFS) /dev/hda15 swap /dev/hda16 /home (JFS) /dev/hda17 1 cylinder aan het eind
Met LVM wiste ik de laatste LVM partitie en maakte ik een minimale "compatibility" (hier FAT) volume aan het eind van de vaste schijf aan en daarna JFS in de overgebleven vrije ruimte. LVM maakt standaard partities in de lege ruimte aan het eind van de schijf aan. Vandaar deze volgorde. De idee was om LVM te dwingen om zowel een begin als een eind aan het non compatibility JFS volume te geven. En dat bleek te werken. De Linux fdisk kon de met semi( lees begrensde) compatibility gevulde JFS partities schijf naar behoren te herkennen. Waarschijnlijk waren de OS/2 en Linux IDE drivers het niet een over het aantal sectoren van de schijf. Maar door het compatibity volume aan het eind van de schijf werd de partitietabel toch netjes ingevuld.
Dergelijke methoden kunnen ook nuttig zijn bij het aanmaken van Window eXtended formaten ( FAT32X), waarbij Windows zoal bekend onjuiste partitietabellen aanmaakt.
240 koppen, 63 sectoren/spoor, 2646 cylinders Eenheden = cylinders van 15120 * 512 = 7741440 bytes Apparaat Opstart Start Einde Blokken Id Systeem /dev/hda1 70 207 1043280 6 FAT16 /dev/hda2 2 69 514080 16 Verborgen FAT16 /dev/hda3 * 1 1 7528+ a OS/2 Boot Manager /dev/hda4 208 2646 18438840 5 Uitgebreid /dev/hda5 * 208 345 1043248+ 6 FAT16 /dev/hda6 * 346 483 1043248+ 6 FAT16 /dev/hda7 * 484 551 514048+ 7 HPFS/NTFS /dev/hda8 * 552 633 619888+ 6 FAT16 /dev/hda9 * 634 904 2048728+ 6 FAT16 /dev/hda10 * 905 918 105808+ 83 Linux /dev/hda11 * 919 1013 718168+ 7 HPFS/NTFS --------------------------------------------------------------- /dev/hda12 * 1014 1284 2048728+ 6 FAT16 /dev/hda13 * 1285 1555 2048728+ 6 FAT16 /dev/hda14 1556 2097 4097488+ 35 Onbekend /dev/hda15 * 2098 2132 264568+ 82 Linux wisselgeheugen /dev/hda16 * 2133 2644 3870688+ 35 Onbekend /dev/hda17 * 2645 2646 15088+ 6 FAT16
Partitietabel ingangen zijn niet in schijfvolgorde
Opdracht (m voor hulp):
Maar Linux bleek niet (zonder fschk) op de onder OS/2 aangemaakte JFS partitie te willen installeren. Een door OS/2 aangemaakte en in fstab aangemeld JFS volume bracht het booten van Linux steeds weer in de problemen. En zeker als die zich aan het eind van de schijf bevond.
Daarna bedacht ik me dat ik wel dat data, maar geen Linux programma's en /etc met OS/2 hoefde te delen. Daarom koos ik voor de volgende configuratie:
/dev/hda10 /boot (EXT3) /dev/hda14 / (Reisser) /dev/hda15 swap /dev/hda16 geen mountpoint (JFS) /dev/hda17 1 cylinder aan het eind
In dit geval wordt /home op /dev/hda14/home (Reisser) gemount.
Het plan was om eerst Linux erop te krijgen en daarna /home naar /dev/hda16 = /data (JFS) te kopiëren en daarna via een aangepaste fstab /data/home als /home te mounten. Dat ziet er dan zo uit:
/dev/hda14 / reiserfs defaults 1 1 /dev/hda16 /data jfs noauto 0 0 /dev/hda10 /boot ext2 defaults 1 2 /dev/hda15 swap swap pri=42 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 proc /proc proc defaults 0 0 usbdevfs /proc/bus/usb usbdevfs noauto 0 0 /dev/cdrom /media/cdrom auto ro,noauto,user,exec 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0
Maar /data was zo niet zomaar te mounten.
Last login: Tue Oct 21 23:27:30 2003 from ecs Have a lot of fun... sjoerd@deskpro:~> su Password: deskpro:/home/sjoerd # mount /data mount: slechte bestandssysteem soort, slechte optie, slecht superblok op /dev/hd a16,of teveel aangekoppelde bestandssystemen deskpro:/home/sjoerd #
Na een fsck (chkdsk) onder Linux ging het wel:
deskpro:/home/sjoerd # fsck /dev/hda16 fsck 1.28 (31-Aug-2002) fsck.jfs version 1.1.1, 17-Dec-2002 The current device is: /dev/hda16 Block size in bytes: 4096 File system size in blocks: 965900 Phase 0 - Replay Journal Log File system is clean. deskpro:/home/sjoerd # mount /data deskpro:/home/sjoerd #
Daarna kopieerde ik als root /home naar /data, hernoemde /home (Reisser) naar de al backup bedoelde home1 (Reisser), maakte een symlink van /data/home (JFS) naar /home (gaat simpel via de nc) en kon daarna als "sjoerd" op /data/home/sjoerd onder JFS werken.
Kortom: eenvoudig is het delen van JFS onder Linux en OS/2 nog niet. En er zijn geen garanties. Maar aan de ander kant geldt dat de intenties van de bestandssysteemmakers (lees: een open source minded IBM) goed is. Anders dan Microsoft met zijn closed source bestandssystemen wil IBM uw data niet in een legacy val opsluiten. U kunt er onder Linux en andere JFS ondersteunende (in de toekomst wellicht die van MS) besturingssystemen goed bij.
Moderne Linux distributies als SuSE 8.2 (mijn testsysteem) ondersteunen het Journaling File System goed. Oudere distributies bevatten Linux JFS implementaties die niet met de OS/2 versie compatibel zijn.
JFS moet met een block size van 4097 bytes aangemaakt zijn. Dit is de standaardwaarde.
Vergeleken met HPFS en FAT, VFAT en FAT32 zijn er onder Linux weinig mount opties aanwezig.
The following mount options are supported: iocharset=name Character set to use for converting from Unicode to ASCII. The default is compiled into the kernel as CONFIG_NLS_DEFAULT. Use iocharset=utf8 for UTF8 translations. This requires CONFIG_NLS_UTF8 to be set in the kernel .config file. resize=value Resize the volume to <value> blocks. JFS only supports growing a volume, not shrinking it. This option is only valid during a remount, when the volume is mounted read-write. The resize keyword with no value will grow the volume to the full size of the partition. Nointegrity Do not write to the journal. The primary use of this option is to allow for higher performance when restoring a volume from backup media. The integrity of the volume is not guaranteed if the system abnormally ends. Integrity Default. Commit metadata changes to the journal. Use this option to remount a volume where the nointegrity option was previously specified in order to restore normal behavior.
Een stukje fstab:
# Met OS/2 gedeelde HPFS en JFS partities /dev/hda10 /mnt/os2bin jfs defaults 1 2 /dev/hda11 /mnt/data jfs defaults 1 2 /dev/sda5 /mnt/usbide jfs defaults 1 2
De laatste ingang betreft een met JFS geformatteerde IDE schijf met een USB 2 interface zoals door Gerrit Schoenmaker beschreven in het VOICE artikel Mounting USB 2.0 harddisk case in eComStation.
SuSE Linux voegt de door haar herkende hot pluggable device dynamisch aan fstab toe. Als u niet weet op welk device uw partities zitten, kunt u dus cat /etc/fstab proberen. Daarnaast geeft fdisk /dev/sda vaak raad.
OS/2 is een single-user systeem. Iedere gebruiker mag op de prompt doen wat hij wil. Als Jan een bestand aanmaakt, kan gebruiker Piet ze wissen. Alleen onder HPFS386 kunnen lokale bestandspermissies worden ingesteld. Maar vanuit Linux bekeken wekt iedere OS/2 gebruiker met een rootaccount.
Linux is daarentegen een multi-user systeem. Ieder bestand krijgt de bestandsrechten van degene die ze maakt of download. Alleen de eigenaar of root mag de bestandspermissies wijzigen. Ze kunnen afhankelijk van de umask variabele scherper of minder scherp ingesteld zijn. Maar ze hebben altijd het user-id (uid) en het groups-id (gid) van een bepaalde gebruiker aan zich gebonden.
Maar voor een bestand of map die u onder OS/2 op een JFS volume zet, geldt dit niet. Als u ze vanuit Linux benadert bezitten ze de uid en gid van root en geen enkele permissie:
232992 d--------- 2 root root 4096 2003-09-11 15:53 licenses 232613 ---------- 1 root root 306846 2002-09-19 17:50 mozjs.dll
Maar dat is met een rootaccount niet zo'n probleem:
sjoerd@suse8:~> su Password: suse8:/home/sjoerd # chown --recursive sjoerd /mnt/data suse8:/home/sjoerd # chgrp --recursive users /mnt/data suse8:/home/sjoerd # chmod --recursive 0711 /mnt/data
U kunt er een script van maken.
#!/bin/bash chown --recursive sjoerd /mnt/data chgrp --recursive users /mnt/data chmod --recursive 0711 /mnt/data
De gewijzigde bestandspermissies gelden alleen voor Linux. Want onder OS/2 werkt u weer met het (vanuit Linux bekeken) root account. OS/2 merkt de UNIX bestandspermissies van JFS niet op. OS/2 doet dus niets met de permissies van een bestaand bestand. Ook niet als u het wijzigt.
Wel moet u er op letten dat uw OS/2 editor UNIX compatibel is als het bestand door Linux moet worden gelezen.! En als u OS/2 tekstbestanden onder Linux bewerkt, moet ze als DOS/OS/2 of Windows bestanden opslaan.
|
Bootable JFS voor eCS en OS/2 heeft sinds 12 juli 2007 de opties /G:gid en /U:id waarmee u het Linux/UNIX groupsid en user ID kunt instellen op JFS. Hiermee worden bestanden niet per se als root aangemaakt. De opdracht is handig voor met Linux gedeelde JFS mappen. IFS=C:\OS2\JFS.IFS /LW:10,30,6 /CACHE:400000 /AUTOCHECK:* /G:100 /U:1000 U achterhaalt uw identificatie waarden met de opdracht id (bijv. id sjoerd) onder Linux. sjoerd@dell820:~> id sjoerd uid=1000(sjoerd) gid=100(users) groepen=16(dialout),33(video),100(users) sjoerd@dell820:~> id root uid=0(root) gid=0(root) groepen=0(root) Bootable JFS laat IFS=C:\OS2\JFS.IFS /G:100 /U:1000 met de bestanden die u eerder als root (id 0, gid 0) aanmaakte onder het root account staan. Ze krijgen echter een GID met de naam disk. Overigens kunt u de type 7 (HPFS/NTFS) bootable JFS bootpartitie niet onder Linux mounten. Schijf /dev/sda: 160.0 GB, 160041885696 bytes 255 koppen, 63 sectoren/spoor, 19457 cilinders Eenheid = cilinders van 16065 * 512 = 8225280 bytes Schijf-ID: 0xe70de70d Apparaat Opstart Begin Einde Blokken ID Systeem /dev/sda1 * 1 1 8001 a OS/2 opstartmanager /dev/sda2 2 27 208845 b W95 FAT32 /dev/sda3 28 91 514080 1b Verborgen W95 FAT32 /dev/sda4 92 19457 155557395 5 Uitgebreid /dev/sda5 92 193 819283+ 7 HPFS/NTFS /dev/sda6 194 219 208813+ 83 Linux /dev/sda7 220 474 2048256 7 HPFS/NTFS /dev/sda8 475 987 4120641 7 HPFS/NTFS /dev/sda9 988 1500 4120641 7 HPFS/NTFS /dev/sda10 1501 6709 41841261 35 [onbekend] /dev/sda11 6710 11583 39150373+ 7 HPFS/NTFS /dev/sda12 11584 13084 12056751 7 HPFS/NTFS /dev/sda13 13085 15634 20482843+ 35 [onbekend] /dev/sda14 15635 16157 4200966 82 Linux wisselgeheugen /dev/sda15 16158 19457 26507218+ 83 Linux Type 35 is wel als jfs te mounten.
|
Maar als u een bestand opnieuw opslaat onder een andere naam of het oude bestand vervangt, dan krijgt het bestand rootrechten. Het wordt dan een nieuw bestand met een ander inode nummer. Het zelfde geldt als de tekstverwerker tijdelijke bestanden aanmaakt of het oorspronkelijke bestand als een bak bestand opslaat. In alle gevallen maakt u via uw tekstverwerker technisch gezien een nieuw bestand aan.
Ik kwam hier tijdens het schrijven van deze tekst achter. Nadat ik deze tekst onder OS/2 bewerkt had, kon ik er plots niet meer bij.
86104 ---------- 1 root root 12924 2003-09-12 22:39 jfs.html 86105 -rwx--x--x 1 sjoerd users 5114 2002-11-11 23:48 links.html 86106 -rwx--x--x 1 sjoerd users 49109 2002-12-03 00:19 lvm.html
In dit geval stond StarOffice zo ingesteld dat het steeds een reservekopie (bak bestand) maakte. Mogelijk hield het bak bestand de rechten van gebruiker sjoerd (ik kon het niet nagaan want het bak bestand zat op HPFS), maar het gewijzigde bestand jfs.html werd blijkbaar als een nieuw bestand opgeslagen. En een nieuw bestand kreeg dus de bij OS/2 behorende rootrechten. Ik zette daarna StarOffice's "Altijd een reserverkopie maken" optie maar uit. Maar tot mijn verbazing had het bestand nog steeds hetzelfde inode nummer, maar was zijn gebruikers- en groeps -ID wel naar die van root veranderd.
86104 ---------- 1 root root 12924 2003-09-
Ik ging weer naar mijn /home/sjoerd/.emacs bestand dat ik opnieuw onder OS/2 met e.exe had bewerkt. Het met Ctrl-S opgeslagen en bewerkte bestand had nog steeds hetzelfde inode nummer en de bijbehorende permissies, alleen de kopie die ik met OS/2's rootrechten als .emacsos2 opsloeg kwam zoals verwacht met exclusieve rootrechten op de wereld. Wat me wel verbaasde was het lage inode nummer van de kopie. Ik had verwacht dat OS/2 er een hoger nummer aan zou toekennen. Blijkbaar was een eerder bestand 4226 al gewist.
5190 -rw-r--r-- 1 sjoerd users 1683 2003-09-13 00:24 .emacs 4226 ---------- 1 root root 1685 2003-09-13 00:24 .emacsos2
Onder Linux worden inode nummers sequentieel toegekend:
sjoerd@suse8:~> touch 1 sjoerd@suse8:~> touch 2 sjoerd@suse8:~> touch 3 sjoerd@suse8:~> touch 4
Levert het volgende op (ik laat niet alles zien):
sjoerd@suse8:~> ls -ila 131165 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:34 1 131166 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:34 2 131167 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:34 3 131169 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:34 4 266241 drwx------ 3 sjoerd users 256 2003-09-12 22:54 Desktop
Als ik nu het bestand met inode nummer 131166 wis:
sjoerd@suse8:~> del 2 Error: Try the command: rm -iv 2 sjoerd@suse8:~> rm -iv 2 rm: remove regular empty file `2'? y removed `2'
En een nieuw bestand 5 aanmaak:
sjoerd@suse8:~> touch 5 sjoerd@suse8:~> ls -ila 131165 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:34 1 131167 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:34 3 131169 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:34 4 131170 -rw-r--r-- 1 sjoerd users 0 2003-09-12 23:39 5
Dan zou je verwachten dat het oude inode nummer vrijkwam en er een nieuw bestand met het vrijgekomen inode nummer wordt aangemaakt. Maar dat bleek hier niet het geval. Was inode nummer 131166 door een ander proces ingepikt? Find heeft een optie hiervoor (type man find, /inode):
-inum n
File has inode number n.Ik laat find erop los, want ik wil het weten.
sjoerd@suse8:~> find -inum 131166 find: ./homepage: Toegang geweigerd
De zoekactie in de home directory leverde niets op (behalve dan dat ik homepage als root onder OS/2 naar /home/sjoerd gekopieerd had.)
sjoerd@suse8:~> su Password: suse8:/home/sjoerd # find -inum 131166
Ik had eigenlijk verwacht dat het verdwenen inode nummer in de als /home gemounte /dev/hda15 OS/2 JFS partitie zou zitten. Maar /homes kwam in de find actie niet voor. Wel andere bestanden in /mnt/os2bin/ waarvan de door find gevonden zoeknamen je het ergste doen vermoeden over de ogenschijnlijke incompatibiliteit van JFS onder Linux en OS/2...
suse8:/home/sjoerd # find / -inum 131166 /mnt/jfs2/k/Sslurp/www1.computerwoche.de/heftarchiv/1996/19960705/a26421.html find: /mnt/os2bin/XFree86/lib/X11/gnome/apps/Games/¶€È Í? Gnome.desktop: Onbekend bestand of map find: /mnt/os2bin/XFree86/lib/X11/gnome/apps/Utilities/Ú?ã€Ê????Ð € Ÿ?ËÈ???....desktop: Onbekend bestand of map /usr/share/texmf/doc/fonts/eurosym/COPYING find: /proc/3528/fd/4: Onbekend bestand of map suse8:/home/sjoerd #
Dergelijke bestandsnamen kunt u beter niet openen. Want als ze al te openen zijn (Onbekend bestand of map) kan OS/2 er daarna niets mee. En dat is vragen om WPS en bootproblemen.
Ik hoop dat dit met de mount optie iocharset=name op te lossen is, want ander is dit compatibiliteitsprobleem onoverkomelijk.
Het inode nummer was waarschijnlijk door een actueel proces (/proc/3528/fd/4) ingepikt. De overige mappen heb ik bij mijn weten niet benaderd. Maar het komt er dus wel op neer dat Linux de inode nummers toebedeeld en dat ook kan doen op een geheel ander station. Blijkbaar weet Linux de inodes van de verschillende partities uit elkaar te houden, maar de door find gegenereerde bestandsnamen stellen me niet gerust.
Toen ik het weer in OpenOffice onder Linux wilde openen kreeg ik geen rechten. Het uitzetten van reservekopie maken hielp ook niet. Nu verdenk ik StarOffice ervan dat het vanuit zijn tijdelijke bestanden in de %TEMP% map steeds weer nieuwe bestand genereert.
Want het verborgen bestand .emacs in mijn /home/sjoerd directory die ik met e opende, bewerkte en met Ctr-S weer opsloeg bleef zijn oude rechten behouden. Alleen als ik het met "Opslaan als" als een nieuw bestand opsloeg, raakte het zijn permissies kwijt.
Ook HPFS is onder Linux te benaderen. De HPFS r/w driver van Mikulas Patocka maakt deel uit van de bij SuSE 8.2 geleverde 2.4.20 kernel. De driver kan de bestandspermissies in de uitgebreide attributen opslaan. Maar het is doorgaans gemakkelijker om de HPFS schijf meteen als gebruiker te benaderen. Dit werkt trouwens ook met FAT, vFAT en FAT32.
/dev/hda7 /mnt/ecs1 hpfs user,gid=100,uid=500,umask=022 1 2 /dev/hda8 /mnt/ecs2 hpfs user,gid=100,uid=500,umask=022 1 2
Uw id is op te vragen met:
sjoerd@suse8:~> id sjoerd uid=500(sjoerd) gid=100(users) groepen=100(users),14(uucp),16(dialout),17(audio),33(video)
Het is wel nuttig om de numerieke User IDs consequent toe te passen, want ook NFS werkt ermee.
Bovenstaande fstab geldt voor user sjoerd (User id 500):
suse8:/mnt/ecs1/os2 # ls -ila totaal 10906 442232 drwxr-xr-x 19 sjoerd users 22528 2003-09-11 17:07 . 2113244 drwxr-xr-x 38 sjoerd users 6144 2003-09-11 00:39 .. 1504061 -rw-r--r-- 1 sjoerd users 6494 2000-05-01 17:48 8514.RC 1504075 -rw-r--r-- 1 sjoerd users 6497 2000-05-01 17:48 8514M.RC 1504089 -rw-r--r-- 1 sjoerd users 5139 2002-03-11 09:04 ANSI.EXE
Let op: de Linux HPFS driver werkt niet altijd goed samen met HPFS386!
JFS Cookbook: Toen dit geschreven werd (16 October 2001) waren er nog allerlei JFS problemen.
Maar Installing eComStation on a JFS Volume is nu een reële optie.