Bug 14647

Can you rerun the strace with '-v -s 1024' ?

I need to see exactly what the lstat call is returning here.

strace -v -s 1024 -f mountpoint /mnt/XXX/:

[...]
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1\0004\0\0\0t\266\23\0\0\0\0\0004\0 \0\n\0(\0C\0B\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0@\1\0\0@\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0\360<\22\0\360<\22\0\360<\22\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\334z\23\0\334z\23\0\5\0\0\0\0\20\0\0\1\0\0\0\0\202\23\0\0\202\23\0\0\202\23\0\234'\0\0pT\0\0\6\0\0\0\0\20\0\0\2\0\0\0\234\235\23\0\234\235\23\0\234\235\23\0\360\0\0\0\360\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0t\1\0\0t\1\0\0t\1\0\0 \0\0\0 \0\0\0\4\0\0\0\4\0\0\0\7\0\0\0\0\202\23\0\0\202\23\0\0\202\23\0\10\0\0\0,\0\0\0\4\0\0\0\4\0\0\0P\345td\4=\22\0\4=\22\0\4=\22\0D+\0\0D+\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\10\202\23\0\0\202\23\0\0\202\23\0\204\34\0\0\200\34\0\0\4\0\0\0\1\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\10\0\0\0\363\3\0\0\n\0\0\0\0\2\0\0\16\0\0\0\2400\20D\200 \2\1\214\3\346\220AE\210\0\204\0\10\0A\200\0@\300\200\0\f\2\f\0\0010\0\10@\"\10\246\4\210H6l\240\0260\0&\204\200\216\4\10B$\2\f\246\244\32\6c\310\0\302 \1\300\0R\0!\201\10\4\n  \250\24\0\24(`\0\0P\240\312DB"..., 512) = 512
fstat64(3, {st_dev=makedev(22, 2), st_ino=1978668, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=2544, st_size=1294572, st_atime=2009/03/26-23:18:27, st_mtime=2009/01/04-19:11:21, st_ctime=2009/03/26-23:19:16}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8032000
mmap2(NULL, 1300080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ef4000
mmap2(0xb802c000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x138) = 0xb802c000
mmap2(0xb802f000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb802f000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef3000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ef36b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb802c000, 4096, PROT_READ)   = 0
munmap(0xb8033000, 25116)               = 0
lstat64("/mnt/XXX/", {st_dev=makedev(0, 16), st_ino=1970324837024262, st_mode=S_IFDIR|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=16384, st_blocks=0, st_size=0, st_atime=2009/11/20-15:07:43, st_mtime=2009/11/20-15:07:43, st_ctime=2009/11/20-15:07:43}) = 0
write(2, "mountpoint: /mnt/XXX/: Value too large for defined data type\n"..., 61mountpoint: /mnt/XXX/: Value too large for defined data type
) = 61
exit_group(1)

It doesn't matter if I test it with a Windows 2000 Server or with Samba.
Also the size does not seem to be involved (I have tried 700GB and 100GB).
Checking any other mointpoint thats not connected via CIFS is also fine.

The problem here is actually that your mountpoint utility isn't built to deal with large files and 64 bit inode numbers.

It's using normal 'lstat()' calls. Under the hood however, glibc turns those calls into lstat64() calls. The kernel returns a 64-bit st_ino value (as it was requested to do). glibc then takes that value and tries to stuff it into the legacy stat struct. That doesn't fit, so it generates an EOVERFLOW in userspace and returns that to the application.

The best solution is to build with LFS defines so that your applications are 64-bit capable. A workaround in the meantime might be to mount with 'noserverino', but that will render the client unable to properly identify hardlinks.

I'm going to go ahead and close this as INVALID. Please reopen if you have questions.