Test for writability fails over NFS. What is going wrong? Or is this a bug?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
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)
permissions nfs
asked Feb 26 at 14:38
Christian Wolf
18616
add a comment |Â
up vote
1
down vote
favorite
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)
permissions nfs
asked Feb 26 at 14:38
Christian Wolf
18616
Are you starting KDE as root?
– Kusalananda
Feb 26 at 15:54
1
Show us the mount on the client and the exports on the server.
– Gerard H. Pille
Feb 27 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. Theroot_squashdoesn'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 withroot_squashactive.
– roaima
Feb 27 at 14:30
I am writing as usercwolfin/home/cwolf. No userrootis involved.
– Christian Wolf
Feb 27 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 at 17:27
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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)
permissions nfs
asked Feb 26 at 14:38
Christian Wolf
18616
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)
permissions nfs
asked Feb 26 at 14:38
Christian Wolf
18616
edited Feb 28 at 9:20
asked Feb 26 at 14:38
Christian Wolf
18616
asked Feb 26 at 14:38
Christian Wolf
18616
asked Feb 26 at 14:38
Christian Wolf
18616
18616
Are you starting KDE as root?
– Kusalananda
Feb 26 at 15:54
1
Show us the mount on the client and the exports on the server.
– Gerard H. Pille
Feb 27 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. Theroot_squashdoesn'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 withroot_squashactive.
– roaima
Feb 27 at 14:30
I am writing as usercwolfin/home/cwolf. No userrootis involved.
– Christian Wolf
Feb 27 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 at 17:27
add a comment |Â
Are you starting KDE as root?
– Kusalananda
Feb 26 at 15:54
1
Show us the mount on the client and the exports on the server.
– Gerard H. Pille
Feb 27 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. Theroot_squashdoesn'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 withroot_squashactive.
– roaima
Feb 27 at 14:30
I am writing as usercwolfin/home/cwolf. No userrootis involved.
– Christian Wolf
Feb 27 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 at 17:27
Are you starting KDE as root?
– Kusalananda
Feb 26 at 15:54
Are you starting KDE as root?
– Kusalananda
Feb 26 at 15:54
1
1
Show us the mount on the client and the exports on the server.
– Gerard H. Pille
Feb 27 at 13:18
Show us the mount on the client and the exports on the server.
– Gerard H. Pille
Feb 27 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 at 14:30
"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 at 14:30
I am writing as user
cwolf in /home/cwolf. No user root is involved.– Christian Wolf
Feb 27 at 17:26
I am writing as user
cwolf in /home/cwolf. No user root is involved.– Christian Wolf
Feb 27 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 at 17:27
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 at 17:27
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
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.
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
Sharp eyes there... Assuming#is the root prompt.
– Kusalananda
Feb 26 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 at 15:36
Well, the OP did not yet confirm it.
– Gerard H. Pille
Feb 26 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 at 17:49
I am sorry, I always miss the difference of$and#at the prompt. I am trying this as usercwolf. I will update the question.
– Christian Wolf
Feb 27 at 12:11
 |Â
show 4 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
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.
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
Sharp eyes there... Assuming#is the root prompt.
– Kusalananda
Feb 26 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 at 15:36
Well, the OP did not yet confirm it.
– Gerard H. Pille
Feb 26 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 at 17:49
I am sorry, I always miss the difference of$and#at the prompt. I am trying this as usercwolf. I will update the question.
– Christian Wolf
Feb 27 at 12:11
 |Â
show 4 more comments
up vote
2
down vote
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.
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
Sharp eyes there... Assuming#is the root prompt.
– Kusalananda
Feb 26 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 at 15:36
Well, the OP did not yet confirm it.
– Gerard H. Pille
Feb 26 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 at 17:49
I am sorry, I always miss the difference of$and#at the prompt. I am trying this as usercwolf. I will update the question.
– Christian Wolf
Feb 27 at 12:11
 |Â
show 4 more comments
up vote
2
down vote
up vote
2
down vote
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.
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
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.
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
answered Feb 26 at 15:28
Gerard H. Pille
1,169212
1,169212
Sharp eyes there... Assuming#is the root prompt.
– Kusalananda
Feb 26 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 at 15:36
Well, the OP did not yet confirm it.
– Gerard H. Pille
Feb 26 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 at 17:49
I am sorry, I always miss the difference of$and#at the prompt. I am trying this as usercwolf. I will update the question.
– Christian Wolf
Feb 27 at 12:11
 |Â
show 4 more comments
Sharp eyes there... Assuming#is the root prompt.
– Kusalananda
Feb 26 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 at 15:36
Well, the OP did not yet confirm it.
– Gerard H. Pille
Feb 26 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 at 17:49
I am sorry, I always miss the difference of$and#at the prompt. I am trying this as usercwolf. I will update the question.
– Christian Wolf
Feb 27 at 12:11
Sharp eyes there... Assuming
# is the root prompt.– Kusalananda
Feb 26 at 15:31
Sharp eyes there... Assuming
# is the root prompt.– Kusalananda
Feb 26 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 at 15:36
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 at 15:36
Well, the OP did not yet confirm it.
– Gerard H. Pille
Feb 26 at 17:43
Well, the OP did not yet confirm it.
– Gerard H. Pille
Feb 26 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 at 17:49
@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 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 at 12:11
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 at 12:11
 |Â
show 4 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f426700%2ftest-for-writability-fails-over-nfs-what-is-going-wrong-or-is-this-a-bug%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Are you starting KDE as root?
– Kusalananda
Feb 26 at 15:54
1
Show us the mount on the client and the exports on the server.
– Gerard H. Pille
Feb 27 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. Theroot_squashdoesn'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 withroot_squashactive.– roaima
Feb 27 at 14:30
I am writing as user
cwolfin/home/cwolf. No userrootis involved.– Christian Wolf
Feb 27 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 at 17:27