1

I have a very strange problem with a NFS mount. I have a Synology NAS serving the home directories for a set of linux machines (Archlinux for the moment). The used protocol is NFS V3.

When I log into the machines using my main user, I can see that I have write permission to my home folder:

$ ls -ld ~
drwx------ 28 cwolf cwolf 4096 26. Feb 15:10 /home/cwolf

I can create and remove files. So the folder is in fact writable.

Now I see a strange behavior. Issuing

$ test -w ~; echo $?
1

indicates that I do not have write permission on my home folder.... This makes KDE to reject from running as it thinks it cannot write to the home folder.

Trying the same with a local user (whose home folder lies completely on the local hard disk), everything is consistent. So the test returns 0.

Can anyone tell me where I can look to solve the problem and make test return the correct value? Also the question is if this is more likly a problem on the NFS server or on the NFS client.


Additional information:

The problem is not related to root_squash as in the exact same session I can do touch foo/rm foo to create and remove a file foo successfully. So the server accepts my commands as user.

Most of the information in the internet is related the other way around: The user is shown to have write access but gets remapped on the server to nobody due to squashing. My problem is that my rights are accepted but shown falsely as read-only rendering tests to fail.


As requested by the comments here the export options on the server:

/volume1/cloud 134.96.8.160/27(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

The mount options (corresponding line from the output of mount) are:

ds2.lsr.uni-saarland.de:/volume1/cloud on /home type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=134.96.8.162,mountvers=3,mountport=892,mountproto=tcp,local_lock=none,addr=134.96.8.162)
  • Are you starting KDE as root? – Kusalananda Feb 26 '18 at 15:54
  • 1
    Show us the mount on the client and the exports on the server. – Gerard H. Pille Feb 27 '18 at 13:18
  • "The problem is not related to root_squash" does not lead on from the example you have given, unless you are writing within, say, /home/cwolf. The root_squash doesn't prevent root from writing; rather, it translates root access to the anonymous/nobody user. If this user can write to a location then root can do so even with root_squash active. – roaima Feb 27 '18 at 14:30
  • I am writing as user cwolf in /home/cwolf. No user root is involved. – Christian Wolf Feb 27 '18 at 17:26
  • You mean the mount options on client and server's exportfs line corresponding to the mount? I will have to start the machine to obtain it. Will do so soon. – Christian Wolf Feb 27 '18 at 17:27
2

You are root when you run this test. Depending on the server settings, this will forbid you to write to that folder. A normal user will not have that problem.

  • Sharp eyes there... Assuming # is the root prompt. – Kusalananda Feb 26 '18 at 15:31
  • I admit, it is a bit of a wild guess. But then he shouldn't have given his normal users a hash prompt. I don't know why I see such things. – Gerard H. Pille Feb 26 '18 at 15:36
  • Well, the OP did not yet confirm it. – Gerard H. Pille Feb 26 '18 at 17:43
  • @roaima I'll not yet add the no_root_squash to my answer, I wonder if the OP knows the consequences of being root. – Gerard H. Pille Feb 26 '18 at 17:49
  • I am sorry, I always miss the difference of $ and # at the prompt. I am trying this as user cwolf. I will update the question. – Christian Wolf Feb 27 '18 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.