2012-08-16, 17:37
(2012-08-15, 22:53)Memphiz Wrote: no_root_squash would map remote user id to server user id - but would map remote id 0 (root) to the anonuser on the server.
...so it does the opposite ... it ensures nothing gets mapped to id 0
Ok, now I'm a bit confused.
"man exports" says the following:
Code:
Very often, it is not desirable that the root user on a client machine is
also treated as root when accessing files on the NFS server. To this end,
uid 0 is normally mapped to a different id: the so-called anonymous or
nobody uid. This mode of operation (called `root squashing') is the
default, and can be turned off with no_root_squash.
By default, exportfs chooses a uid and gid of 65534 for squashed access.
These values can also be overridden by the anonuid and anongid options.
Finally, you can map all user requests to the anonymous uid by specifying
the all_squash option.
Here's the complete list of mapping options:
root_squash
Map requests from uid/gid 0 to the anonymous uid/gid. Note that
this does not apply to any other uids or gids that might be equally
sensitive, such as user bin or group staff.
no_root_squash
Turn off root squashing. This option is mainly useful for diskless
clients.
all_squash
Map all uids and gids to the anonymous user. Useful for NFS-
exported public FTP directories, news spool directories, etc. The
opposite option is no_all_squash, which is the default setting.
anonuid and anongid
These options explicitly set the uid and gid of the anonymous
account. This option is primarily useful for PC/NFS clients, where
you might want all requests appear to be from one user. As an exam‐
ple, consider the export entry for /home/joe in the example section
below, which maps all requests to uid 150 (which is supposedly that
of user joe).I think you meant to say:
Quote:root_squash would map remote user id to server user id - but would map remote id 0 (root) to the anonuser on the server.
Tell me if you think the following is correct:
no_root_squash only turns off root squashing, but I wasn't connecting from XBMCBuntu as root, so no_root_squash probably had nothing to do with it, and It worked because I removed "all_squash". XBMCBuntu was probably able to connect because it was using uid=1000, and uid=1000 has access on the server.
XBMCBuntu would have worked just as well if I had neither used all_squash nor no_root_squash, and only said "192.168.1.0/24(ro,insecure)", because uid=1000 has access on the server - but it would not have worked from the iPad, because that runs as the uid=501.
If I had said "all_squash,insecure,anonuid=1000,anongid=1000", it should then send all access to uid=1000, and should then work from both the iPad and XBMCBuntu.
I'll test this and report back.
To recap, here's what definitely works so far:
- 192.168.1.0/24(ro,no_root_squash,insecure) - gives access to XBMCBuntu with uid=1000, but NOT iPad with uid=501 because uid=1000 has access, but uid=501 is mapped to nobody (65534) which does not have access
- 192.168.1.0/24(ro,all_squash,insecure,anonuid=0,anongid=0) - gives access to XBMCBuntu with uid=1000 AND iPad with uid=501, because everyone is mapped to root (uid=0)
- 192.168.1.0/24(ro,insecure) - will give access to XBMCBuntu with uid=1000, but NOT iPad with uid=501
- 192.168.1.0/24(ro,all_squash,insecure,anonuid=1000,anongid=1000) - will give access to XBMCBuntu with uid=1000 AND iPad with uid=501, because they are both mapped to uid=1000, which has access on the server
-Wes
- its easy once you know what all this means right? ^^
