The setup ( although dont trust anything I say ):

I'm working on an embedded system device using a NFS mounted rootfs ( as shared by my host ) , but I store large video content directly on the device's hdd in /data.

Device's hdd partition /dev/sda3 is ext3 fs mounted at /tmp/mnt/diska3 (rw) , then I have a script create dirs like /tmp/mnt/diska3/data
and /tmp/mnt/diska3/data/incoming, then symlink : ln -s /tmp/mnt/diska3/data /data so that the /data appears like any other directory.

I can see /tmp/mnt/diska3/data/incoming. I did chmod -R a+w tmp to rule out permissions.

Running a subsequent script calls mkdir: mkdir -p /data/incoming/gui

BUT fails:
mkdir: cannot create directory '/data/': No such file or directory

What's the deal?

Thanks for use of your brain.. dB

You don't state that you've verified that /data exists and that the process that is running the makdir has permission to write to /. (Typically, permission to modify the root is restricted to processes with uid=0.)

Did you try an ls -l / and look at the permissions on the link as well as the link target?

If he didn't have permissions it would tell him that rather than that the directory doesn't exist. Can you post your code? If you are doing everything that you described it sounds like it should be working. I can maybe see it giving you problems if sda3 was no longer mounted. Verify that /data exists and is linked to the right place and that sda3 is still mounted when you are trying to run mkdir. Good luck.

I have an older working system and noted some differences. Before I start hacking maybe someone can spot the problem while I read up on this. There could be extraneous / wrong stuff on the old system but it does function. I believe the script that fails mkdir is run as root.

OLD (WORKING):
as seen from host:
lrwxrwxrwx 1 nfsnobody nfsnobody 20 2010-01-13 09:57 data -> /tmp/mnt/diska3/data
drwxrwxrwx 2 root root 4096 2009-11-10 11:33 tmp

as seen from target device:
lrwxrwxrwx 1 65534 nogroup 20 Jan 13 2010 data -> /tmp/mnt/diska3/data
drwxrwxrwt 4 root root 140 Jan 3 01:07 tmp
[ in /tmp ]
drwxr-xr-x 5 root root 100 Jan 1 00:00 mnt
[ in mnt ]
drwxrwxrwx 7 root root 4096 Sep 4 2000 diska3


NEW (FAILS:
as seen from host:
lrwxrwxrwx 1 root root 20 2010-05-30 09:45 data -> /tmp/mnt/diska3/data
drwxr-xr-x 2 root root 4096 2010-05-25 11:58 tmp

as seen from target device:
lrwxrwxrwx 1 root root 20 May 30 2010 data -> /tmp/mnt/diska3/data
drwxrwxrwt 4 root root 120 Nov 28 05:33 tmp
[ in /tmp ]
drwxr-xr-x 4 root root 80 Nov 28 05:33 mnt
[ in mnt ]
drwxrwxrwx 4 root root 4096 Nov 26 06:38 diska3

Potentially solved:
I chmod 777 /tmp on host side ( was 755 ) . I'm a tad fuzzy on this but I believe root isn't really root on the target side, bbut rather nsfnobody with uid = 65534 not 0, so although root could do whatever, the effective uid couldn't write in /tmp/.

But stay tuned - I did change some other stuff so maybe that wasn't it....

Well, slightly more complicated - a reboot reset permissions in /tmp/mnt so I had to chmod -r 777 AT BOOT just before running real scripts.