for my own records
Today I undertook probably one of the most risky steps in my life as a system administrator...
Since getting my MacBook, I always wanted to be able to mount Network
File Servers (nfs) from home and work on it, so that I didn't have to ssh every file back and forth
between machines. This by itself is not a very trivial task, mostly due to Mac having a rather
unintuitive interface for mounting external file servers.
So on Linux side it's rather straight forwards:
a) install an nfs server, get it to run.
b) edit the /etc/exports file, add a line saying
/directory_to_export ip_address(rw,sync)
(if you want it to be read-write, that is)
Then go to *another* Linux, and
a) "import" (mount, that is) the file server by editing the /etc/fstab,
adding the following line:
exporting_machine_ip_address:/directory_to_export /mount_point nfs 0 0
b) do mount /directory_to_export
c) all of the above under root or sudo, of course
The problem is that Mac is not "*another* Linux", it has it's own utilities, which
at times are similar to Linux, and at times (this being that time) not very much so.
The equivalent is done using either the NetInfo Manager gui, or niutil utility at the prompt.
I did it all using the gui, because the command line utility is way too unintuitive.
The detailed description of the next steps can be found under
http://mactechnotes.blogspot.com/2005/08/mac-os-x-as-nfs-client_31.html
So in NetInfo Manager all you do is go to "mounts", "add a Directory", give the "name" as "exporting_machine_ip_address:/directory_to_export", "type" as "nfs", and for
"opts" choose "-P". After this you kill the autoconf (I guess it's some daemon which
functions like mount, except that mount is not a daemon) using
sudo kill -1 `cat /var/run/automount.pid`
which kills and restarts the process.
At this point, you notice that you got a /directory_to_export under your
/Networks/Servers/exporting_machine_ip_address...and sure enough it's empty.
From past experience you suspect it's the options ("opts") variable.
Reading through the above mentioned web page, you see that some people get things
to run with the following flags for "opts": resvport,rw,net,sync
Change that, and -- kuku -- it works! You can see the file system on the
remote machine!
In euphoria, you go and start reading things, how beautiful, and try to
write something...bummer!! It's all read only! But I had the "rw" in opts,
what can be wrong now?? Well, duh, it's the User ID (uid) that you use.
If you run
id
on both machines, you'll see that the values are different. On most of the linux
machines, the "main" account is id-ed at 1000, while in Mac it's 501. As longs
as they are different, the nfs will allow operations only to within the "others"
permission setting (which is typically read-only, and sometimes not even that).
Here come three choices:
a) figure out a way of changing the UID on MAC
b) try the same on the Linux box instead, or...
c) change everything of the /directory_to_export with a
chmod o+rwx *
(c) is clearly madness, it makes the Linux box highly insecure.
(b) is not very easy, but not very optimal: what if you need to export that nfs to other Linux boxes?
chances are your MAC is going to be the only non-Linx on the tree of exported nfs-es.
So you are stuck with having to do (a). Unlike on Linux, changing a UID on Mac is a
MAJOR
pain. Chaging the user ID itself is next to trivial: you do it either in the same NetInfo Manager,
or by simply logging in as a root and doing:
niutil -createprop . /users/userName uid 1000
to change it from 501 to 1000
And then you find out that you are in a mess. ALL your files are under UID 501, while you yourself are UID 1000:
your user account, with ALL its files doesn't belong to you anymore!!
The temptation is to run back to root and revert niutil to uid 501.
However, there is a fix: it involves scanning the WHOLE file system and changing the ownership for all
files belonging to uid=501 to the current user (i.e. uid=1000). This can be done with the
all powerful find command:
find / -user 501 -exec chown userName {} \;
This is what I ended up doing. And while the find was working (5min), I felt like visiting the bathroom at
least a dozen of times: if it were to go wrong at any point for any reason, a significant section of my
file system would become off limits for me. Fortunately it seems to have worked fine, and after
having rebooted the machine, just to be sure, everything, with the exception of one or two tiny
glitches, seems to be working fine. The only files whose ownership did not change, for some
reason, are the links. But there probably should be a simple way of doing chown for thos too,
I need to find out.
p.s. so in retrospect, the uid change was a bit of an overkill. I could have, in the /etc/export,
simply specified
/directory_to_export ip_address(rw,map_static=/etc/file.map)
where file.map would consist of simply
uid 501 1000
this would statically map 501 on client to 1000 on server.
Since getting my MacBook, I always wanted to be able to mount Network
File Servers (nfs) from home and work on it, so that I didn't have to ssh every file back and forth
between machines. This by itself is not a very trivial task, mostly due to Mac having a rather
unintuitive interface for mounting external file servers.
So on Linux side it's rather straight forwards:
a) install an nfs server, get it to run.
b) edit the /etc/exports file, add a line saying
/directory_to_export ip_address(rw,sync)
(if you want it to be read-write, that is)
Then go to *another* Linux, and
a) "import" (mount, that is) the file server by editing the /etc/fstab,
adding the following line:
exporting_machine_ip_address:/directory_to_export /mount_point nfs 0 0
b) do mount /directory_to_export
c) all of the above under root or sudo, of course
The problem is that Mac is not "*another* Linux", it has it's own utilities, which
at times are similar to Linux, and at times (this being that time) not very much so.
The equivalent is done using either the NetInfo Manager gui, or niutil utility at the prompt.
I did it all using the gui, because the command line utility is way too unintuitive.
The detailed description of the next steps can be found under
http://mactechnotes.blogspot.com/2005/08/mac-os-x-as-nfs-client_31.html
So in NetInfo Manager all you do is go to "mounts", "add a Directory", give the "name" as "exporting_machine_ip_address:/directory_to_export", "type" as "nfs", and for
"opts" choose "-P". After this you kill the autoconf (I guess it's some daemon which
functions like mount, except that mount is not a daemon) using
sudo kill -1 `cat /var/run/automount.pid`
which kills and restarts the process.
At this point, you notice that you got a /directory_to_export under your
/Networks/Servers/exporting_machine_ip_address...and sure enough it's empty.
From past experience you suspect it's the options ("opts") variable.
Reading through the above mentioned web page, you see that some people get things
to run with the following flags for "opts": resvport,rw,net,sync
Change that, and -- kuku -- it works! You can see the file system on the
remote machine!
In euphoria, you go and start reading things, how beautiful, and try to
write something...bummer!! It's all read only! But I had the "rw" in opts,
what can be wrong now?? Well, duh, it's the User ID (uid) that you use.
If you run
id
on both machines, you'll see that the values are different. On most of the linux
machines, the "main" account is id-ed at 1000, while in Mac it's 501. As longs
as they are different, the nfs will allow operations only to within the "others"
permission setting (which is typically read-only, and sometimes not even that).
Here come three choices:
a) figure out a way of changing the UID on MAC
b) try the same on the Linux box instead, or...
c) change everything of the /directory_to_export with a
chmod o+rwx *
(c) is clearly madness, it makes the Linux box highly insecure.
(b) is not very easy, but not very optimal: what if you need to export that nfs to other Linux boxes?
chances are your MAC is going to be the only non-Linx on the tree of exported nfs-es.
So you are stuck with having to do (a). Unlike on Linux, changing a UID on Mac is a
MAJOR
pain. Chaging the user ID itself is next to trivial: you do it either in the same NetInfo Manager,
or by simply logging in as a root and doing:
niutil -createprop . /users/userName uid 1000
to change it from 501 to 1000
And then you find out that you are in a mess. ALL your files are under UID 501, while you yourself are UID 1000:
your user account, with ALL its files doesn't belong to you anymore!!
The temptation is to run back to root and revert niutil to uid 501.
However, there is a fix: it involves scanning the WHOLE file system and changing the ownership for all
files belonging to uid=501 to the current user (i.e. uid=1000). This can be done with the
all powerful find command:
find / -user 501 -exec chown userName {} \;
This is what I ended up doing. And while the find was working (5min), I felt like visiting the bathroom at
least a dozen of times: if it were to go wrong at any point for any reason, a significant section of my
file system would become off limits for me. Fortunately it seems to have worked fine, and after
having rebooted the machine, just to be sure, everything, with the exception of one or two tiny
glitches, seems to be working fine. The only files whose ownership did not change, for some
reason, are the links. But there probably should be a simple way of doing chown for thos too,
I need to find out.
p.s. so in retrospect, the uid change was a bit of an overkill. I could have, in the /etc/export,
simply specified
/directory_to_export ip_address(rw,map_static=/etc/file.map)
where file.map would consist of simply
uid 501 1000
this would statically map 501 on client to 1000 on server.