Solved Mounting NFSv4 directory modifies directory destination permissions

pipolandi

pipolandi

Hello, I have an NFS server running on Debian 'testing'. The server is working fine with other computers of the local net ( one with Debian 'testing' , and the other with Windows). Also, the firewall has the right instructions to allow traffic to my NFS client on FreeBSD 10.1. The server directory is: 192.168.2.3:/mnt/datos. The client destination directory is: /mnt/servidor.

Before trying to mount the server directory, the destination directory has the following permissions:
Code: 
drwxr-xr-x  2 error  error  512 Nov 26 21:46 servidor
error is my username.

After mounting the server directory with #mount_nfs -o nfsv4 192.168.2.3:/mnt/datos /mnt/server (no error output on the console), the directory permissions change to:
Code: 
drwxrwx---+ 11 1000  1000  4096 Nov 23 22:21 servidor
so I can not see inside of it. If I do (root or normal user) ls servidor, I get:
Code: 
total 0
ls: servidor: Permission denied
Neither can I change the directory permissions when it is mounted. However it seems that the server directory has been mounted without problems.
df -h output:
Code: 
Filesystem  Size  Used  Avail Capacity  Mounted on
/dev/ada0p3  68G  22G  41G  35%  /
devfs  1.0K  1.0K  0B  100%  /dev
/dev/ada0p4  368G  34M  338G  0%  /mnt/datos
procfs  4.0K  4.0K  0B  100%  /proc
linprocfs  4.0K  4.0K  0B  100%  /compat/linux/proc
fdescfs  1.0K  1.0K  0B  100%  /dev/fd
/dev/fuse  0B  0B  0B  100%  /usr/home/error/.gvfs
192.168.2.3:/mnt/datos  1.7T  1.6T  104G  94%  /mnt/servidor
When I unmount the destination directory /mnt/servidor I get:
Code: 
umount: 192.168.2.3: MOUNTPROG: RPC: Port mapper failure - RPC: Timed out
but the servidor directory has been unmounted, recovering the original permissions.

I can sync directories with the server using rsync -av without problems.

This is my rc.conf:
Code: 
hostname="error"
performance_cpu_freq="HIGH"

keymap="spanish.iso15.acc.kbd"
keyrate="fast"

firewall_enable="YES"
firewall_type="open" #for testing purpose #

ifconfig_rl0="inet 192.168.1.7 netmask 255.255.255.0"
ifconfig_alx0="inet 192.168.2.4 netmask 255.255.255.0"
defaultrouter="192.168.1.1"

moused_enable="YES"
ntpd_enable="YES"
dumpdev="NO"
hald_enable="YES"
dbus_enable="YES"
kdm4_enable="YES"

devfs_system_ruleset="localrules"

nfs_client_enable="YES"
nfs_client_flags="-n 4"
rpc_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
I also tried disabling rpc_statd_enable, rpc_statd_enable and rpc_enable.

The question is: why are the permissions of the client directory servidor changed?

Thanks in advance.
 
NFSv4 uses a mapping scheme for UIDs, instead of the old approach to just assume the UIDs are identical for the same user on different machines. You're probably just missing the FreeBSD implementation for it, nfsuserd(8).
 
acheron and Zirias, many thanks for your answers. Problem solved :) :beer:

I added
Code: 
nfsuserd_enable="YES"
to my rc.conf on my FreeBSD machine, but nothing happened. Because of acheron's question I decided to change the permissions of the server directory.

The permissions on /mnt/datos were:
Code: 
drwxr-x---  4 minegrita  minegrita  1024 Dec  1 09:26 datos
Changed it to
Code: 
drwxr-xrwx  4 minegrita  minegrita  1024 Dec  1 09:26 datos
That was the solution.

However in my Debian client machine, I did not need to change the permissions for 'others' in the server directory. Another question arises: why do I need to change the permissions on the server directory in order to get a functional FreeBSD client?

Again, many thanks for your answers :)
 
acheron said:
Looks weird, what are the UID of minegrita on the client and server?
Click to expand...
The minegrita user does not exist on the FreeBSD client machine, it only exists on the server.

id minegrita
Code: 
uid=1000(minegrita) gid=1000(minegrita) grupos=1000(minegrita),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev)
 
It needs to exist on both machines and have the same UID/GID. You will be able to remove the 'other' permission on the share after fixing that.
 
acheron said:
It needs to exist on both machine and have the same UID/GID. You will be able to remove the 'other' perm on the share after fixing that.
Click to expand...
I will try it, but when I was on Debian as a client, I did not need to have a minegrita user.

Thanks.
 
You must log in or register to reply here.
Back
Top