2

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)
5
  • Are you starting KDE as root?
    – Kusalananda
    Feb 26, 2018 at 15:54
  • 1
    Show us the mount on the client and the exports on the server. Feb 27, 2018 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, 2018 at 14:30
  • I am writing as user cwolf in /home/cwolf. No user root is involved. Feb 27, 2018 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. Feb 27, 2018 at 17:27

2 Answers 2

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.

9
  • Sharp eyes there... Assuming # is the root prompt.
    – Kusalananda
    Feb 26, 2018 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. Feb 26, 2018 at 15:36
  • Well, the OP did not yet confirm it. Feb 26, 2018 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. Feb 26, 2018 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. Feb 27, 2018 at 12:11
0

I recently had the same issue.

I am using a Synology NAS, and the problem has been resolved after updating the DSM (operating system) to the latest. Hope it helps the ones struggling with the same problem.

1
  • 1
    Welcome to U&L. Maybe you could expand your answer a bit by for example quoting the relevant part from the new OS release notes or similar (with link to the source)? That'll make it possible for others to verify whether the answer is correct. Feb 20 at 8:36

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.