NFS Share Permissions - on Debian

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












0














server: machine-1
client: machine-2 or any machine in the allowed-subnet.



I have created NFSv4 server on machine-1: How can I ensure that:



in the NFS folder all newly directories from machine-2 to be created with 775, and files to be created with 664 permission.










share|improve this question























  • Please clarify the NFS version used, and whether you mean file/directory creation mask (i.e. mode bits removed from 666 or 777) or the resulting file/directory creation mode. Directory mask 600 or 622 makes any created directories unusable to their owner as the owner-read and owner-write bits will be masked out (= you cannot add anything to the new directory). If interpreted as directory mode instead, it also won't work as the owner-access bit will be missing (=you cannot access anything within the directory).
    – telcoM
    Dec 16 at 12:02










  • NFSv4, ok let me rephrase and make it something realistic, in the NFS folder all newly directories to be created with 775, and files to be created with 664 permission.
    – Imrank
    Dec 16 at 12:05











  • im thinking that I should chmod the directory to 777 and file to 666: then the default value of umask 0002 will do the work.. but I do not know how exactly to proceed this.
    – Imrank
    Dec 16 at 12:07










  • Please edit your original question instead of making comments that will completely change the original question: comments are not permanent, and after the comments expire, the ultimately accepted answer to the changed question would make no sense at all to new readers seeing only the original unchanged question.
    – telcoM
    Dec 16 at 12:19










  • please tell me if the question makes sense now?
    – Imrank
    Dec 16 at 12:28















0














server: machine-1
client: machine-2 or any machine in the allowed-subnet.



I have created NFSv4 server on machine-1: How can I ensure that:



in the NFS folder all newly directories from machine-2 to be created with 775, and files to be created with 664 permission.










share|improve this question























  • Please clarify the NFS version used, and whether you mean file/directory creation mask (i.e. mode bits removed from 666 or 777) or the resulting file/directory creation mode. Directory mask 600 or 622 makes any created directories unusable to their owner as the owner-read and owner-write bits will be masked out (= you cannot add anything to the new directory). If interpreted as directory mode instead, it also won't work as the owner-access bit will be missing (=you cannot access anything within the directory).
    – telcoM
    Dec 16 at 12:02










  • NFSv4, ok let me rephrase and make it something realistic, in the NFS folder all newly directories to be created with 775, and files to be created with 664 permission.
    – Imrank
    Dec 16 at 12:05











  • im thinking that I should chmod the directory to 777 and file to 666: then the default value of umask 0002 will do the work.. but I do not know how exactly to proceed this.
    – Imrank
    Dec 16 at 12:07










  • Please edit your original question instead of making comments that will completely change the original question: comments are not permanent, and after the comments expire, the ultimately accepted answer to the changed question would make no sense at all to new readers seeing only the original unchanged question.
    – telcoM
    Dec 16 at 12:19










  • please tell me if the question makes sense now?
    – Imrank
    Dec 16 at 12:28













0












0








0







server: machine-1
client: machine-2 or any machine in the allowed-subnet.



I have created NFSv4 server on machine-1: How can I ensure that:



in the NFS folder all newly directories from machine-2 to be created with 775, and files to be created with 664 permission.










share|improve this question















server: machine-1
client: machine-2 or any machine in the allowed-subnet.



I have created NFSv4 server on machine-1: How can I ensure that:



in the NFS folder all newly directories from machine-2 to be created with 775, and files to be created with 664 permission.







ubuntu permissions nfs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 16 at 12:28

























asked Dec 15 at 21:52









Imrank

53




53











  • Please clarify the NFS version used, and whether you mean file/directory creation mask (i.e. mode bits removed from 666 or 777) or the resulting file/directory creation mode. Directory mask 600 or 622 makes any created directories unusable to their owner as the owner-read and owner-write bits will be masked out (= you cannot add anything to the new directory). If interpreted as directory mode instead, it also won't work as the owner-access bit will be missing (=you cannot access anything within the directory).
    – telcoM
    Dec 16 at 12:02










  • NFSv4, ok let me rephrase and make it something realistic, in the NFS folder all newly directories to be created with 775, and files to be created with 664 permission.
    – Imrank
    Dec 16 at 12:05











  • im thinking that I should chmod the directory to 777 and file to 666: then the default value of umask 0002 will do the work.. but I do not know how exactly to proceed this.
    – Imrank
    Dec 16 at 12:07










  • Please edit your original question instead of making comments that will completely change the original question: comments are not permanent, and after the comments expire, the ultimately accepted answer to the changed question would make no sense at all to new readers seeing only the original unchanged question.
    – telcoM
    Dec 16 at 12:19










  • please tell me if the question makes sense now?
    – Imrank
    Dec 16 at 12:28
















  • Please clarify the NFS version used, and whether you mean file/directory creation mask (i.e. mode bits removed from 666 or 777) or the resulting file/directory creation mode. Directory mask 600 or 622 makes any created directories unusable to their owner as the owner-read and owner-write bits will be masked out (= you cannot add anything to the new directory). If interpreted as directory mode instead, it also won't work as the owner-access bit will be missing (=you cannot access anything within the directory).
    – telcoM
    Dec 16 at 12:02










  • NFSv4, ok let me rephrase and make it something realistic, in the NFS folder all newly directories to be created with 775, and files to be created with 664 permission.
    – Imrank
    Dec 16 at 12:05











  • im thinking that I should chmod the directory to 777 and file to 666: then the default value of umask 0002 will do the work.. but I do not know how exactly to proceed this.
    – Imrank
    Dec 16 at 12:07










  • Please edit your original question instead of making comments that will completely change the original question: comments are not permanent, and after the comments expire, the ultimately accepted answer to the changed question would make no sense at all to new readers seeing only the original unchanged question.
    – telcoM
    Dec 16 at 12:19










  • please tell me if the question makes sense now?
    – Imrank
    Dec 16 at 12:28















Please clarify the NFS version used, and whether you mean file/directory creation mask (i.e. mode bits removed from 666 or 777) or the resulting file/directory creation mode. Directory mask 600 or 622 makes any created directories unusable to their owner as the owner-read and owner-write bits will be masked out (= you cannot add anything to the new directory). If interpreted as directory mode instead, it also won't work as the owner-access bit will be missing (=you cannot access anything within the directory).
– telcoM
Dec 16 at 12:02




Please clarify the NFS version used, and whether you mean file/directory creation mask (i.e. mode bits removed from 666 or 777) or the resulting file/directory creation mode. Directory mask 600 or 622 makes any created directories unusable to their owner as the owner-read and owner-write bits will be masked out (= you cannot add anything to the new directory). If interpreted as directory mode instead, it also won't work as the owner-access bit will be missing (=you cannot access anything within the directory).
– telcoM
Dec 16 at 12:02












NFSv4, ok let me rephrase and make it something realistic, in the NFS folder all newly directories to be created with 775, and files to be created with 664 permission.
– Imrank
Dec 16 at 12:05





NFSv4, ok let me rephrase and make it something realistic, in the NFS folder all newly directories to be created with 775, and files to be created with 664 permission.
– Imrank
Dec 16 at 12:05













im thinking that I should chmod the directory to 777 and file to 666: then the default value of umask 0002 will do the work.. but I do not know how exactly to proceed this.
– Imrank
Dec 16 at 12:07




im thinking that I should chmod the directory to 777 and file to 666: then the default value of umask 0002 will do the work.. but I do not know how exactly to proceed this.
– Imrank
Dec 16 at 12:07












Please edit your original question instead of making comments that will completely change the original question: comments are not permanent, and after the comments expire, the ultimately accepted answer to the changed question would make no sense at all to new readers seeing only the original unchanged question.
– telcoM
Dec 16 at 12:19




Please edit your original question instead of making comments that will completely change the original question: comments are not permanent, and after the comments expire, the ultimately accepted answer to the changed question would make no sense at all to new readers seeing only the original unchanged question.
– telcoM
Dec 16 at 12:19












please tell me if the question makes sense now?
– Imrank
Dec 16 at 12:28




please tell me if the question makes sense now?
– Imrank
Dec 16 at 12:28










1 Answer
1






active

oldest

votes


















0














First, just chmod the shared folder on machine-1 to whatever you want it to be.



If all the users on any client machine (or at least those that actually write to the share) have their umask values set to 002, you should not - in theory - need to do anything else.



However, if you cannot be sure of the umask values of the client machines, you might want to add a default ACL to the shared folder before creating any sub-folders. To do that, make sure the filesystem on the server machine-1 that actually contains the shared folder has ACL support enabled, and do this:



setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1


As a result, getfacl /shared/folder/on/machine-1 should now return:



# file: /shared/folder/on/machine-1
# owner: <username of folder owner>
# group: <group name>
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x


The last three lines describe the permissions automatically applied for any sub-folders and files created to this folder from this point on. Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file.






share|improve this answer




















  • So according to my need, I should chmod 775 to "/shared/folder/on/machine-1", and then apply the acl: 'setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1' so this will just cater the directories to set to 775, what about the newly created files which needs to have permissions of 664 in the NFS shared folder.
    – Imrank
    Dec 16 at 14:58










  • "Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file." Basically, the default permissions set works sort of like an umask, although it is expressed very differently.
    – telcoM
    Dec 16 at 15:01










  • so to me, I think this could be achieved via taking the directory mode for newly file to 777 , and file mode to 666 then, the default umask value is set 0002 on machine-1 (not considering the umask of other machines in the network), that would do the work.. 0666-0002= 664 & 0777-0002=775. But the problem is I do not know how to set dir-> 777 & file->666 on NFS directory because as I am changing the mode: the mount on the network machine fails with the "permission Denied"
    – Imrank
    Dec 16 at 15:02










  • When a new file or directory is created to a NFS filesystem on machine-2, the umask on machine-1 is not consulted at all. If you cannot chmod something, you are not its owner. If the default root_squash NFS export option is in effect, it makes the root of the NFS client be equivalent to nobody on the NFS-mounted filesystem. So if the directory is owned by root, you must actually log on machine-1 and become root there to make the change. On a NFS-mounted filesystem, a regular user with proper group membership can easily be more powerful than the root user of the NFS client system.
    – telcoM
    Dec 16 at 15:11











  • You are right, i shared the NFS with the root_squash option ON. and before sharing i -> chown nobody:nogroup "/shared/folder/on/machine-1" to meet the requirement of my task. Does it mean unless i do no_root_squash: my config won't work?
    – Imrank
    Dec 16 at 18:26










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489222%2fnfs-share-permissions-on-debian%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














First, just chmod the shared folder on machine-1 to whatever you want it to be.



If all the users on any client machine (or at least those that actually write to the share) have their umask values set to 002, you should not - in theory - need to do anything else.



However, if you cannot be sure of the umask values of the client machines, you might want to add a default ACL to the shared folder before creating any sub-folders. To do that, make sure the filesystem on the server machine-1 that actually contains the shared folder has ACL support enabled, and do this:



setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1


As a result, getfacl /shared/folder/on/machine-1 should now return:



# file: /shared/folder/on/machine-1
# owner: <username of folder owner>
# group: <group name>
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x


The last three lines describe the permissions automatically applied for any sub-folders and files created to this folder from this point on. Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file.






share|improve this answer




















  • So according to my need, I should chmod 775 to "/shared/folder/on/machine-1", and then apply the acl: 'setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1' so this will just cater the directories to set to 775, what about the newly created files which needs to have permissions of 664 in the NFS shared folder.
    – Imrank
    Dec 16 at 14:58










  • "Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file." Basically, the default permissions set works sort of like an umask, although it is expressed very differently.
    – telcoM
    Dec 16 at 15:01










  • so to me, I think this could be achieved via taking the directory mode for newly file to 777 , and file mode to 666 then, the default umask value is set 0002 on machine-1 (not considering the umask of other machines in the network), that would do the work.. 0666-0002= 664 & 0777-0002=775. But the problem is I do not know how to set dir-> 777 & file->666 on NFS directory because as I am changing the mode: the mount on the network machine fails with the "permission Denied"
    – Imrank
    Dec 16 at 15:02










  • When a new file or directory is created to a NFS filesystem on machine-2, the umask on machine-1 is not consulted at all. If you cannot chmod something, you are not its owner. If the default root_squash NFS export option is in effect, it makes the root of the NFS client be equivalent to nobody on the NFS-mounted filesystem. So if the directory is owned by root, you must actually log on machine-1 and become root there to make the change. On a NFS-mounted filesystem, a regular user with proper group membership can easily be more powerful than the root user of the NFS client system.
    – telcoM
    Dec 16 at 15:11











  • You are right, i shared the NFS with the root_squash option ON. and before sharing i -> chown nobody:nogroup "/shared/folder/on/machine-1" to meet the requirement of my task. Does it mean unless i do no_root_squash: my config won't work?
    – Imrank
    Dec 16 at 18:26















0














First, just chmod the shared folder on machine-1 to whatever you want it to be.



If all the users on any client machine (or at least those that actually write to the share) have their umask values set to 002, you should not - in theory - need to do anything else.



However, if you cannot be sure of the umask values of the client machines, you might want to add a default ACL to the shared folder before creating any sub-folders. To do that, make sure the filesystem on the server machine-1 that actually contains the shared folder has ACL support enabled, and do this:



setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1


As a result, getfacl /shared/folder/on/machine-1 should now return:



# file: /shared/folder/on/machine-1
# owner: <username of folder owner>
# group: <group name>
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x


The last three lines describe the permissions automatically applied for any sub-folders and files created to this folder from this point on. Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file.






share|improve this answer




















  • So according to my need, I should chmod 775 to "/shared/folder/on/machine-1", and then apply the acl: 'setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1' so this will just cater the directories to set to 775, what about the newly created files which needs to have permissions of 664 in the NFS shared folder.
    – Imrank
    Dec 16 at 14:58










  • "Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file." Basically, the default permissions set works sort of like an umask, although it is expressed very differently.
    – telcoM
    Dec 16 at 15:01










  • so to me, I think this could be achieved via taking the directory mode for newly file to 777 , and file mode to 666 then, the default umask value is set 0002 on machine-1 (not considering the umask of other machines in the network), that would do the work.. 0666-0002= 664 & 0777-0002=775. But the problem is I do not know how to set dir-> 777 & file->666 on NFS directory because as I am changing the mode: the mount on the network machine fails with the "permission Denied"
    – Imrank
    Dec 16 at 15:02










  • When a new file or directory is created to a NFS filesystem on machine-2, the umask on machine-1 is not consulted at all. If you cannot chmod something, you are not its owner. If the default root_squash NFS export option is in effect, it makes the root of the NFS client be equivalent to nobody on the NFS-mounted filesystem. So if the directory is owned by root, you must actually log on machine-1 and become root there to make the change. On a NFS-mounted filesystem, a regular user with proper group membership can easily be more powerful than the root user of the NFS client system.
    – telcoM
    Dec 16 at 15:11











  • You are right, i shared the NFS with the root_squash option ON. and before sharing i -> chown nobody:nogroup "/shared/folder/on/machine-1" to meet the requirement of my task. Does it mean unless i do no_root_squash: my config won't work?
    – Imrank
    Dec 16 at 18:26













0












0








0






First, just chmod the shared folder on machine-1 to whatever you want it to be.



If all the users on any client machine (or at least those that actually write to the share) have their umask values set to 002, you should not - in theory - need to do anything else.



However, if you cannot be sure of the umask values of the client machines, you might want to add a default ACL to the shared folder before creating any sub-folders. To do that, make sure the filesystem on the server machine-1 that actually contains the shared folder has ACL support enabled, and do this:



setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1


As a result, getfacl /shared/folder/on/machine-1 should now return:



# file: /shared/folder/on/machine-1
# owner: <username of folder owner>
# group: <group name>
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x


The last three lines describe the permissions automatically applied for any sub-folders and files created to this folder from this point on. Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file.






share|improve this answer












First, just chmod the shared folder on machine-1 to whatever you want it to be.



If all the users on any client machine (or at least those that actually write to the share) have their umask values set to 002, you should not - in theory - need to do anything else.



However, if you cannot be sure of the umask values of the client machines, you might want to add a default ACL to the shared folder before creating any sub-folders. To do that, make sure the filesystem on the server machine-1 that actually contains the shared folder has ACL support enabled, and do this:



setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1


As a result, getfacl /shared/folder/on/machine-1 should now return:



# file: /shared/folder/on/machine-1
# owner: <username of folder owner>
# group: <group name>
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x


The last three lines describe the permissions automatically applied for any sub-folders and files created to this folder from this point on. Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 16 at 14:49









telcoM

15.7k12143




15.7k12143











  • So according to my need, I should chmod 775 to "/shared/folder/on/machine-1", and then apply the acl: 'setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1' so this will just cater the directories to set to 775, what about the newly created files which needs to have permissions of 664 in the NFS shared folder.
    – Imrank
    Dec 16 at 14:58










  • "Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file." Basically, the default permissions set works sort of like an umask, although it is expressed very differently.
    – telcoM
    Dec 16 at 15:01










  • so to me, I think this could be achieved via taking the directory mode for newly file to 777 , and file mode to 666 then, the default umask value is set 0002 on machine-1 (not considering the umask of other machines in the network), that would do the work.. 0666-0002= 664 & 0777-0002=775. But the problem is I do not know how to set dir-> 777 & file->666 on NFS directory because as I am changing the mode: the mount on the network machine fails with the "permission Denied"
    – Imrank
    Dec 16 at 15:02










  • When a new file or directory is created to a NFS filesystem on machine-2, the umask on machine-1 is not consulted at all. If you cannot chmod something, you are not its owner. If the default root_squash NFS export option is in effect, it makes the root of the NFS client be equivalent to nobody on the NFS-mounted filesystem. So if the directory is owned by root, you must actually log on machine-1 and become root there to make the change. On a NFS-mounted filesystem, a regular user with proper group membership can easily be more powerful than the root user of the NFS client system.
    – telcoM
    Dec 16 at 15:11











  • You are right, i shared the NFS with the root_squash option ON. and before sharing i -> chown nobody:nogroup "/shared/folder/on/machine-1" to meet the requirement of my task. Does it mean unless i do no_root_squash: my config won't work?
    – Imrank
    Dec 16 at 18:26
















  • So according to my need, I should chmod 775 to "/shared/folder/on/machine-1", and then apply the acl: 'setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1' so this will just cater the directories to set to 775, what about the newly created files which needs to have permissions of 664 in the NFS shared folder.
    – Imrank
    Dec 16 at 14:58










  • "Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file." Basically, the default permissions set works sort of like an umask, although it is expressed very differently.
    – telcoM
    Dec 16 at 15:01










  • so to me, I think this could be achieved via taking the directory mode for newly file to 777 , and file mode to 666 then, the default umask value is set 0002 on machine-1 (not considering the umask of other machines in the network), that would do the work.. 0666-0002= 664 & 0777-0002=775. But the problem is I do not know how to set dir-> 777 & file->666 on NFS directory because as I am changing the mode: the mount on the network machine fails with the "permission Denied"
    – Imrank
    Dec 16 at 15:02










  • When a new file or directory is created to a NFS filesystem on machine-2, the umask on machine-1 is not consulted at all. If you cannot chmod something, you are not its owner. If the default root_squash NFS export option is in effect, it makes the root of the NFS client be equivalent to nobody on the NFS-mounted filesystem. So if the directory is owned by root, you must actually log on machine-1 and become root there to make the change. On a NFS-mounted filesystem, a regular user with proper group membership can easily be more powerful than the root user of the NFS client system.
    – telcoM
    Dec 16 at 15:11











  • You are right, i shared the NFS with the root_squash option ON. and before sharing i -> chown nobody:nogroup "/shared/folder/on/machine-1" to meet the requirement of my task. Does it mean unless i do no_root_squash: my config won't work?
    – Imrank
    Dec 16 at 18:26















So according to my need, I should chmod 775 to "/shared/folder/on/machine-1", and then apply the acl: 'setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1' so this will just cater the directories to set to 775, what about the newly created files which needs to have permissions of 664 in the NFS shared folder.
– Imrank
Dec 16 at 14:58




So according to my need, I should chmod 775 to "/shared/folder/on/machine-1", and then apply the acl: 'setfacl -m d:u::rwx,d:g::rwx,d:o::rx /shared/folder/on/machine-1' so this will just cater the directories to set to 775, what about the newly created files which needs to have permissions of 664 in the NFS shared folder.
– Imrank
Dec 16 at 14:58












"Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file." Basically, the default permissions set works sort of like an umask, although it is expressed very differently.
– telcoM
Dec 16 at 15:01




"Regular files will have the execute permission automatically omitted, unless the program creating the file specifically indicates it wants to create an executable file." Basically, the default permissions set works sort of like an umask, although it is expressed very differently.
– telcoM
Dec 16 at 15:01












so to me, I think this could be achieved via taking the directory mode for newly file to 777 , and file mode to 666 then, the default umask value is set 0002 on machine-1 (not considering the umask of other machines in the network), that would do the work.. 0666-0002= 664 & 0777-0002=775. But the problem is I do not know how to set dir-> 777 & file->666 on NFS directory because as I am changing the mode: the mount on the network machine fails with the "permission Denied"
– Imrank
Dec 16 at 15:02




so to me, I think this could be achieved via taking the directory mode for newly file to 777 , and file mode to 666 then, the default umask value is set 0002 on machine-1 (not considering the umask of other machines in the network), that would do the work.. 0666-0002= 664 & 0777-0002=775. But the problem is I do not know how to set dir-> 777 & file->666 on NFS directory because as I am changing the mode: the mount on the network machine fails with the "permission Denied"
– Imrank
Dec 16 at 15:02












When a new file or directory is created to a NFS filesystem on machine-2, the umask on machine-1 is not consulted at all. If you cannot chmod something, you are not its owner. If the default root_squash NFS export option is in effect, it makes the root of the NFS client be equivalent to nobody on the NFS-mounted filesystem. So if the directory is owned by root, you must actually log on machine-1 and become root there to make the change. On a NFS-mounted filesystem, a regular user with proper group membership can easily be more powerful than the root user of the NFS client system.
– telcoM
Dec 16 at 15:11





When a new file or directory is created to a NFS filesystem on machine-2, the umask on machine-1 is not consulted at all. If you cannot chmod something, you are not its owner. If the default root_squash NFS export option is in effect, it makes the root of the NFS client be equivalent to nobody on the NFS-mounted filesystem. So if the directory is owned by root, you must actually log on machine-1 and become root there to make the change. On a NFS-mounted filesystem, a regular user with proper group membership can easily be more powerful than the root user of the NFS client system.
– telcoM
Dec 16 at 15:11













You are right, i shared the NFS with the root_squash option ON. and before sharing i -> chown nobody:nogroup "/shared/folder/on/machine-1" to meet the requirement of my task. Does it mean unless i do no_root_squash: my config won't work?
– Imrank
Dec 16 at 18:26




You are right, i shared the NFS with the root_squash option ON. and before sharing i -> chown nobody:nogroup "/shared/folder/on/machine-1" to meet the requirement of my task. Does it mean unless i do no_root_squash: my config won't work?
– Imrank
Dec 16 at 18:26

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489222%2fnfs-share-permissions-on-debian%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay