so i've used linux for years (mandrake) and i've never seen this...
i'm sure its a security setting somewhere that i just don't know about
basicly i have a raid array that i share via nfs. works great. well i download stuff on the server and save it to the nfs share, and the files are there on the server.
but i can't see them on the clients.

my exports file is basicly

192.168.1.2 (rw,no_all_squash)
etc...
etc...

and the clients all mount the share in there rc.local

mount 192.168.1.1:/share /share

but on the clients i can't see the files. if i log in via root and ls i can see the file but thats it, if i try anything i get an input/output error.
so whats the problem? what security option does debian have switched?
thank you very much!

ps the server does have two nics, but the 'outside' is the only one firewalled.

Why mount in rc.local as opposed to fstab?

mounting in rc.local probably mounts as root & then may be owned by root. Maybe this is why only root can see the files?

there may also been UID mapping problems. What are the permissions on the directories, are all the 'o' bits off? If so, this may be the problem.

haha i don't know, i should mount in the fstab :-p. i think because i put all my "on boot" stuff in rc.local, i've gotten lazy over the years(less time on the pc)

yea i think that could be it. but whats this about 'o' bits ? that could be it too. i think i might have to yahoo this one. let me know tho.

thanks agian
*edit: root can see the files, but can't do anything with them. they actully only come up for the "ls" command, konqueror and other tools can't see them

hehe sorry... by the 'o' bits, I mean the "others" in the permissions, i.e. "chmod o-rwx foo" would remove all the 'o' bits. (I don't know if the "'o' bits" is even the proper term, to be honest).

To be more thorough, -rwxrw-r-- has just the read bit turned on for "others". if the read and execute bits aren't turned on for others on the directories inside the share, then you wouldn't be able to get into them, assuming the UID aren't mapped the same across both machines.

By UID's not mapped the same, I mean user joe_schmoe is UID 501 on the server, but maybe he's 505 on the client. In that event, joe_schmoe becomes an other on the client even though he's the owner on the server.

yea i think everything on my share is 'chmod 553' or 773 respectivly. actully i'll bet its all 777 haha, i have been getting lazy latley. i'm at work till 6am so i can't check it from here. however i think its the uids that are causing the problem. i used to run NIS a LONG time ago when i had diskless clients (i remember the days of 'free time' :-) ). and my server is the same since then but the clients aren't. so i'll bet my new debian installs have different uids (depending on what order i set the users up on each machine) that would make sense right? thats what no_all_squash was for, i think. yea because mandrake i wanted to say started everything at 500 or something and inceremented by one with each new account. thats gotta be it!
carlos mancia this is for you:
ooooooo dee-de-dee :-p i'm an idiot!!! :-D haha, but brian regan is better. :-)

hey thanks for jogging my brain and giving me something to do at work :-)

dee-de-dee times 2 *i think its nap time at work :-D*

wait so it could also be that the mounting machine(s) don't have the same premissions. they are getting mounted as rw for root and ro for everyone else. humm that could be it to.