Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Consistent UIDs may solve file transfer issues' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Consistent UIDs may solve file transfer issues
Authored by: ldm on Oct 26, '05 11:39:39AM

It does indeed matter.

I have a Linux server at home with 2 Macs (G5 & PB) as well as another PC (linux). My user uses the same UID all over the place. This was particularly important for sharing the iTunes library which happens to sit on an NFS share on the linux server. It is also a good idea to give sane groups to the users to make sure that sharing (again the iTunes lib) across users does not raises any issues.

This is the reason (consistency of UIDS) behind the existence of yellow page systems like NIS where there is a centralized database that stores all users their uids and gids and where all clients consults the NIS server to authenticate and allways use the same uid. There is only one machine to update with NIS: the NIS server itself. The "local" machines do not store the uid/gid data.



---
--
Laurent



[ Reply to This | # ]
let's sort out different cases here
Authored by: davidduff on Oct 26, '05 03:14:58PM

just to avoid incorrect inferences being made here...

i suggest that we distinguish different cases here:

1. write files onto a device (usb key drive, firewire drive, etc.) and "share" files by taking the device from one machine to another.

2. filesharing using one of the standard filesharing protocols (nfs, cifs, afp ...).

a) where the machines are in a common "cluster" of some sort - i.e., using a common network server (netinfo, windows domain server, etc.) for authentication/account info, such as client to server or client to client in an environment with a central server.

b) where the machines are independent - i.e. with no common repository of authentication/account info, i.e. peer-to-peer sharing.

it was my belief that in case #1, the UID matters. files are written onto the device and the only user/group info stored on the device is the uid/gid numbers (not names). so if you try to write something as user "fred", uid 501 on machine a, then disconnect it and take it over to machine b where "barney" is 501 and "fred" is 502, then barney will be able to read it and fred won't.

it was my belief that in cases 2a UID matters indirectly in the sense that you authenticate against a central authentication server and then all machines you talk to who use the same server will recognize your uid.

it was my belief that in case 2b UID is irrlevant. when you connect to the other server, you must authenticate separately. so using the example above, if you are fred on machine a and you want to access files on machine b, you must first authenticate on machine b. when you authenticate, you do so by providing username and password (not uid), so fred on machine a could authenticate as barney on machine b (who happens to have the same uid) or as fred on machine b (different uid). in either case, the (mis-)match of uid's is irrelevant.

some of the statements above would seem to challenge these beliefs, however... anyone have a concrete case to describe?



[ Reply to This | # ]
Thanks!
Authored by: hamarkus on Oct 26, '05 04:11:55PM

Thanks for the clearest description of the issue I have ever seen.

Do I understand it correctly that 1b is only relevant if the box: 'Ignore Ownership on this device" is not checked?
And would it make sense to leave this box unchecked in a "b" scenario anyway (assuming the device is not used for permission relevant stuff like backing up operating systems)?
Could any problems arising from a 1b scenario be simply solved by checking that box?
And what happens if the box gets checked? Are permissions still stored but simply no longer enforced and can they be recovered by unchecking that box again?



[ Reply to This | # ]
In your case 2b
Authored by: gshenaut on Oct 26, '05 05:03:43PM
if I understand you, you have two machines A, B which share files via, say, NFS, and you have a different UID on each machine. First, you work from machine A, and create a file F on machine B using UID-A (the file is owned by UID-A). Then later on, you work from machine B and try to access F using UID-B, and fail. Is that what you meant ?

Greg Shenaut

[ Reply to This | # ]

In your case 2b
Authored by: hamarkus on Oct 27, '05 12:36:02AM

Yes, that is what I meant. Except that I have not tried it out yet. I would just like to know whether I will have problems when I try to do this.



[ Reply to This | # ]
In your case 2b
Authored by: gshenaut on Oct 27, '05 08:30:55AM
If your experience is like mine, you will. We share files like that all the time, and went to constant uid/gid long ago in response to exactly that problem.

Greg Shenaut

[ Reply to This | # ]