Separate Users Partition - PROs & CONs

[Chris]

I'd like to hear your opinion on having the user homes on a separate partition (in case you are using mobile accounts).
So far i have been partitioning disks with a script that runs
before imaging, creating a 60gig System partition and filling the rest of the drive with a second partition, mounted to /Users with an fstab entry. I'm considering going back to one single partition.

PROs for separate partitions:
- Being able to reimage the system with the user's data staying untouched
- Preventing the users from filling their HDs, as they can't write to the System partition.

CONs:
- more complicated

What do you guys think?

[tlarkin]

I would say it totally depends on your environment and goals. For me, I never see myself ever having to wipe the and reload the system partition and not the users. Typically, when I have to reimage a computer it is due to file system corruption, and I gotta wipe the whole drive.

I would say for me personally, it is just too much work for not enough reward. However, that is just me personally. I'd rather build a crash plan, put data in the cloud and implement better data back up policies to ensure lowest amount of down time and the fastest ability to transfer a user from computer to computer if need be.

However, I see the value in it and can understand why that might be ideal in some places.

-Tom

[robb1068]

We went to a separate Users partition a couple years ago for the same reasons you mentioned. There have been a handful of times where it's paid off, either in being able to re-image the System partition (corruption or upgrades) or allowing a large data partition with multiple user home folders.

However, Lion client didn't appear to like that setup when using FileVault. With the System partition encrypted, it would periodically drop the mobile accounts located on the data partition. Have not had a chance to do any additional testing.

[bentoms]

Robb1068, can you please share how you partitioned & made the user accounts on the partition?

[nessts]

we create a partition called UserData and then put this /etc/fstab file in our image
#
# Warning - this file should only be modified with vifs(8)
#
# Failure to do so is unsupported and may be destructive.
#
LABEL=UserData /Users hfs rw 1 0

then any partition named UserData mounts at /Users and everything just works.

[bentoms]

Cheers Todd!!

I'm guessing this is in the 1st boot script? Does it run before Casper creates your local admin account or do you have that located elsewhere?

[nessts]

as for pros/cons
pro: i often get systems that the users call and something is wrong, and if i cannot fix it in 30 minutes of working on it, i will just re-image, i can do so and not worry about loosing the users data.

if you are going to a new OS and you have a 3 partition system you can put the new os on the second os partition and let users test, if they need to go back for a piece of software that no longer works under the new os they can by just holding option key at boot or we can change the boot disk via bless for them.

allows you to let your lower level deskside people be able to reimage a broken system instead of escalating to upper levels to debug something wrong with the os. things i have seen that i have yet to figure out why they happen, admin group disappears on systems which is easy enough for me to fix with a dseditgroup command but only if we have a sudo account setup that does not require the admin group :), but the lower level guy is not as good at command line stuff. so he can just reimage and get the user going. we have had os corruption that prevents system from booting get the folder with a question mark, and instead of having to target disk mode and copy data off the disk, we can just image it again and the user data is there. it comes in more handy than not in my opinion.

cons: i really don't have any problems, except during the imaging process that 8.4 is not partitioning correctly so i have to do it manually.
also, you cannot do the thin imaging methodology of a lot of folks on this list, where you just push your changes to a new machine to get it to the proper image. but since my users are not admins and our images have a lot of software and customization for security etc. i don't personally get a lot of benefit from thin imaging.

[nessts]

/etc/fstab file gets delivered as part of a system setup package we deploy.

[bentoms]

Thanks again.

Can you explain that fstab bit again? What's in the file & when?

I'm THE mac guy in my company with a global population of around 140, will be 200 by end of year.

I only started in march & rebuilt all macs to cs5 & 10.6. This year they want 10.7 (& I'll upgrade to cs5.5 whilst there). Seeing how the bosses want to keep the macs current (have latest mac OS within a year). I'm thinking this workflow could save me sometime down the years!

[bentoms]

Doh I get it. Thanks!!

[tkimpton]

Great idea thanks very much for this

[mconners]

I too am interested in this. Beyond what I have seen posted by nests, are there any other methods that people are using? thanks

[tlarkin]

/etc/fstab doesn't exist by default, but since OS X is based on NeXT which is based on the BSD Kernel, it will actually abide by the /etc/fstab if you create the file, since most Unix based systems do.

I used to use it in the past to configure mounts, but I had an issue with it here and there, and it was so long ago I could not remember it, so I no longer use it.

Just my experience is all, I am sure everyone has varying mileage on this. When I created my separate user's partition I used symbolic links to just point /Users -> /Volumes/data. Though my schema never made it into production, testing only.

-Tom

[Chris]

I too am interested in this. Beyond what I have seen posted by nests, are there any other methods that people are using? thanks

I guess it could also be done with MCX,
there's some info in this thread:
https://jamfnation.jamfsoftware.com/discussion.html?id=2126

When I created my separate user's partition I used symbolic links to just point /Users -> /Volumes/data. Though my schema never made it into production, testing only.

I seem to remember that when i tried that i ran into problems when installing packages with the FEU option.
It failed with an error like "target is not a directory" or something like that.
Must have been back when Casper was at version 6 or early 7,
and OS 10.4/10.5 though...

[nessts]

we did the link originally, i don't remember the specific problems but there were many. we went away from it as fast as possible.

[jbush]

I put the Users Folder on a separate drive all together. The second drive holds the OS X and Windows boot camp user Directories, plus any Virtual machines.
A simple symbolic link to the OS X home directory works great.
ln -s /Volumes/"second drive name"/"Users Directory Folder" / Users

[acdesigntech]

I can't speak to the cons of the other posters, but we have a separate partition for the Users directory with a symbolic link to /Users. Works like a charm. reimaging is a BREEZE. There are some quirks when trying to create packages with Composer and setting things to FEU, but I've worked around them with a post-flight script to sync over the necessary directories to existing users. FUT works as expected.

For my money, I would NEVER go back to having the /Users directory on the boot partition.

[bentoms]

Thanks Andrew.

Could you please elaborate more on the post-flight script?

[acdesigntech]

bentoms, sorry I didn't see this until this morning. I can surely explain:

We have a post flight that basically loops through the Users' directory and rsyncs files to where they need to do, then makes sure permissions are set properly, la:

for i in `ls /Users/`; do case $i in *"admin" | "Shared" | "gat") ## our expected admins and Shared, skip these accounts when found continue ;; *) defaults write /Users/$i/Library/Preferences/com.apple.desktop Background '{default = {ImageFilePath = "/Library/Desktop Pictures/$4"; };}' ## $4 is passed in as an argument via policy. This way we can change the background to whatever we want with this generic script chown $i /Users/$i/Library/Preferences/com.apple.desktop.plist chmod 700 /Users/$i/Library/Preferences/com.apple.desktop.plist ;;
esac
done

## Do it again for the user template
defaults write /System/Library/User Template/English.lproj/Library/Preferences/com.apple.desktop Background '{default = {ImageFilePath = "/Library/Desktop Pictures/mvv_1680x1050a_02062012.jpg"; };}'

Right now we are changing user desktop wallpaper, but replace "defaults write" with rsync -avE or ditto, or cp (only if you don't care about resource forks).

[drlogic]

If you are going to use fstab, rather than referring to the UserData partition by label, use the UUID instead, otherwise you would see problems if a user attaches storage with the same label (as mentioned by Oxford Uni yesterday at our user conf in London).

You can get the UUID from Disk Utility by selecting the partition and then using command-I, or by using diskutil info <device node> in terminal.

[tkimpton]

Thanks drlogic. Do you know the syntax of a script to get the UUID of the volume label passing it to fstab? Don't really fancy going round all the machines to get the different UUID on each machine :(

[tkimpton]

Think we needd that script promised by Oxford Uni at the user conf in London!

[designbridge]

Did anyone get a copy of the Oxford Uni script?

[bentoms]

Finally posted how i do it, http://macmule.com/2012/07/31/how-to-use-fstab-within-a-casper-imaging-workflow/