Jza Posted November 23, 2005 Report Share Posted November 23, 2005 (edited) I got a desktop and laptop both running mandrake 2006, on my desktop I ran draknfs and I typed my laptop IP and Read-Only set to NO. when I want to move a file to the NFS patition it says permission denied, is there any way I can make it able to run. Edited November 23, 2005 by Jza Quote Link to comment Share on other sites More sharing options...
michaelz92 Posted November 25, 2005 Report Share Posted November 25, 2005 do you mean NTFS partition. if so, NTFS partitions are not writable within Linux(or you can but it is in BETA)..it is read only. Quote Link to comment Share on other sites More sharing options...
polemicz Posted November 25, 2005 Report Share Posted November 25, 2005 The obvious, which you may have checked, is check the permissions of the directory you are trying to write in. I myslf am always running into this and it's usually been a permissions issue. Quote Link to comment Share on other sites More sharing options...
Jza Posted November 27, 2005 Author Report Share Posted November 27, 2005 (edited) do you mean NTFS partition. if so, NTFS partitions are not writable within Linux(or you can but it is in BETA)..it is read only. <{POST_SNAPBACK}> I said NFS Network File Sharing. I ran draknfs and I shared some directories with the IP of my laptop but I can't write there. And I assigned Read-only to NO. Edited November 27, 2005 by Jza Quote Link to comment Share on other sites More sharing options...
lavaeolus Posted November 27, 2005 Report Share Posted November 27, 2005 the problem is, if the partition or directory on the nfs-server does not have the correct file permissions for your user it wont let you write, make sure that you connect as a user who has rights to write in the directory Quote Link to comment Share on other sites More sharing options...
Jza Posted November 28, 2005 Author Report Share Posted November 28, 2005 (edited) the problem is, if the partition or directory on the nfs-server does not have the correct file permissions for your user it wont let you write, make sure that you connect as a user who has rights to write in the directory <{POST_SNAPBACK}> How can I do that, I currently have the /etc/exports are like this: /home/jza/ *(no_all_squash,async,insecure,rw) Any other thing that should be there? Edited November 28, 2005 by Jza Quote Link to comment Share on other sites More sharing options...
lavaeolus Posted November 28, 2005 Report Share Posted November 28, 2005 (edited) the export looks ok (at least from the nfs-side) you could put all the users that should have write access in the group users and make the local directory on the server writable for this group sorry, I don't have a nfs-server at hand at the moment of this writing, so I can't tell you the exact permissions, but the above way should do it the problem with nfs or samba is, you have your local file permissions and the file permissions of the network service, but if your local permissions prevent your user from writing to the directory, you can't write even if nfs or smb is configured to be writable the local permissions supersede the permissions of the network service (smb, nfs) example: local directory belongs to joe user and is writable for group users, exported through nfs with no_all_squash, rw now jane user who does not belong to group users connects, she can't write on it until she becomes a member of the group users yes, this sometimes is a pain in the a.. Edited November 28, 2005 by lavaeolus Quote Link to comment Share on other sites More sharing options...
Jza Posted November 29, 2005 Author Report Share Posted November 29, 2005 the local permissions supersede the permissions of the network service (smb, nfs) example: local directory belongs to joe user and is writable for group users, exported through nfs with no_all_squash, rw now jane user who does not belong to group users connects, she can't write on it until she becomes a member of the group users yes, this sometimes is a pain in the a.. <{POST_SNAPBACK}> OK I put some folders on Shared. Something like picture, hopes it works now. Quote Link to comment Share on other sites More sharing options...
aioshin Posted November 29, 2005 Report Share Posted November 29, 2005 just my suggestion, why not use sftp intstead? just enable sshd on both then type sftp://ip on konqueror and then enter user and password then you have all the access on your users home on that other box... no special config.. that is if main goal is just for file transfer Quote Link to comment Share on other sites More sharing options...
pmpatrick Posted November 30, 2005 Report Share Posted November 30, 2005 Following up on aioshin's suggestion, as long as you have ssh set up, you can also just type: fish://<insert ip of remote box> in the address bar of konqueror and do the smae thing. You will also be prompted for your user name and password. For the occasional simple file transfer, it's easier than setting up nsf. Quote Link to comment Share on other sites More sharing options...
sellis Posted November 30, 2005 Report Share Posted November 30, 2005 Do your user ID numbers match up on the server and the client? If not, then your permissions will be all over the place. I had this effect when trying to set up shared directories between two computers at home, but deleting the users and recreating them with the right IDs solved the problem. Quote Link to comment Share on other sites More sharing options...
lavaeolus Posted November 30, 2005 Report Share Posted November 30, 2005 Do your user ID numbers match up on the server and the client? Oh, yes I forgot on this, the usernames are mostly irrelevant, the UIDs are what matters, but since I have all users on my systems configured with the same ID's (LDAP is your friend), I did not think of this, sorry Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.