pyneighborhood

No write access to a share

Asked by colinjones

I am using pyNeighborhood 0.5.0-rc4 on Ubuntu 9.10 to map a SAMBA share from another Ubuntu box. This share was mappable with write access using my old XP machine, now I am trying to mount it with pyNeighborhood and can mount no problems, but have no write access. It creates the correct mount folders, representing the "domain" and machine name, and these have write access permissions. But the share folder itself is set to be owned by root and not writable.

If I sudo -s at a terminal and then try to write to the share it works fine... just not from the desktop, and I really don't want to have to start any desktop apps as sudo just to write to this mounted share...

Question information

Language:
English Edit question
Status:
Solved
For:
pyneighborhood Edit question
Assignee:
No assignee Edit question
Solved by:
colinjones
Solved:
Last query:
Last reply:
Revision history for this message
Patrick Geltinger (patlkli) said : 		#1

This is probably a CIFS problem, as the CIFS Unix Extensions provide the files' UIDs and GIDs from the server, which most likely do *not* match those on the client side.

As a workaround, you could specify specific mount options in the Settings window of pyNeighborhood:

uid=<your uid>,gid=<gid>

These options override the permissions given by the server, so that the specified uid/gid own all files and directories in the mounted share.

To determine your uid and gid, you may use the command "id" in the terminal.

Revision history for this message
colinjones (colin-a-jones) said : 		#2

Thanks Patrick - do you mean I need to specify uid and gid of my desktop login on the client side? I'm not clear on how this works, but how will the server side know what these uid/gids are? The 2 machines do not have their user databases sync'd in any way (like NIS?) so won't the server be confused by the uid, given that there is no guarantee that my uid on the client means anything on the server side? Or am I missing the point here?

Revision history for this message
colinjones (colin-a-jones) said : 		#3

... actually, thinking about it, you seem to be saying get the uid/gid from the server side and provide those to pyN on the client side.... still not really understanding what this does... is it just ignoring the default ones supplied by the server because they don't match anything locally?

Revision history for this message
colinjones (colin-a-jones) said : 		#4

yep, on the client side I set the uid and gid of the desktop logon account I am using and that fixed it. Seems a little strange from a purely user point of view that this was effectively a local permissions issue, as the server-side logon and password had been supplied, and so there was no issue with remote permissions.... even if this is because there is an assumption of consistent uid/gid numbering between server and client, this is definitely something that could be made more logical for the average user.

Thanks heaps for your help!

Revision history for this message
Patrick Geltinger (patlkli) said : 		#5

I admit that this appears somehow strange to the user.

In fact, the server provides its own uid and gid from its passwd. The client side then tries to fit these to its local passwd and that's what goes wrong, or rather isn't what the ordinary user wants it to do.