[Klug-general] NFS + GIDs

[jwm- art.net]

I'm halfway there now. Changed /etc/idmapd.conf on both client and server
so that Nobody-User and Nobody-Group all specify my common user/group. The
client sees all files as owned by common user and common group. The server
sees files created on the server as owned by user who created them, but
files created on client are owned by 65534 - which is the id of the nobody
user in debian (nobody user under arch is 99).









On 4 November 2012 15:14, jwm- art.net <jwm.art.net at gmail.com> wrote:

> I found somewhere to change a nfs-common.conf setting on both client and
> serve to USE_IDMAPD="yes" which I have done, but now the files are owned by
> nobody and nogroup, that is ID 65534 and still not 10000 like I wish.
>
> drwxrwsr-x   2 nobody nogroup  4096 Nov  4 14:47 shared
>
> Both machines have rpc.idmapd running.
>
> Have also read NFS 4 does not work with UID/GIDs.
>
> James.
>
>
>
>
> On 4 November 2012 14:21, jwm- art.net <jwm.art.net at gmail.com> wrote:
>
>> Hello,
>>
>> Hoping someone can help... I've setup NFS to run under Arch Linux, and a
>> client running Debian.
>>
>> From the client machine, the UIDs + GIDs of files look like so:
>>
>> -rw-r--r-- 1 4294967294 4294967294  0 Nov  4 14:05 pop
>> -rw-r--r-- 1 4294967294 4294967294 12 Nov  4 13:11 test
>>
>> I want at least for the GID to have some sensible value and decided to
>> create a new group on both machines with the same GID of 10000. So in the
>> /etc/exports I have this:
>>
>> /srv/nfs/shared
>> Laptop(rw,all_squash,sync,no_subtree_check,anongid=10000)
>>
>> setup as per: https://wiki.archlinux.org/index.php/Nfs#Server
>>
>> And in the client's /etc/fstab:
>>
>> Desktop:/srv/nfs/shared       /desktop/shared       nfs
>> rw,bg,hard,intr 0 0
>>
>> I didn't want to set anonuid in the server /etc/exports as I want to give
>> two user accounts on the client rw access to a shared folder, and ro access
>> to another folder.
>>
>> Thanks for any help,
>> James.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/kent/attachments/20121104/fab80c8e/attachment.html>