On our Red Hat 5.4 servers, Samba often returns disk-free info for devices other than what a user is requesting it for. This seems to be caused by the assumption that a device is uniquely identifying. With NFS shares, at least on RHEL 5, this is not the case. Starting with line 63 in source3/lib/sysquotas.c we have the following: if ( sys_stat(path, &S) == -1 ) return (-1); devno = S.st_dev ; fp = setmntent(MOUNTED,"r"); if (fp == NULL) { return -1; } while ((mnt = getmntent(fp))) { if ( sys_stat(mnt->mnt_dir,&S) == -1 ) continue ; if (S.st_dev == devno) { (*mntpath) = SMB_STRDUP(mnt->mnt_dir); (*bdev) = SMB_STRDUP(mnt->mnt_fsname); (*fs) = SMB_STRDUP(mnt->mnt_type); First, a stat call is executed for the path (normally '.'). The code then loops through all mounted file systems (executing a stat call on them) looking for a file system which has the same device as the path statted earlier. Since the device is not unique, there is a chance this routine returns mntpath/bdev/fs data for the wrong mount. Below is the output of a small test program which shows a list of file systems with the same device: [root@inv0107 ~]# /home/nxp21031/test.pl 0 - /sys 3 - /proc 11 - /dev/pts 17 - /dev/shm 18 - /proc/sys/fs/binfmt_misc 22 - /var/lib/nfs/rpc_pipefs 23 - /home/cdspip_workareas 24 - /home/gbr02444, /home/nlv06125, /home/nlv07939, /home/nlv08101, /home/nlv09275 25 - /home/nlv04455, /home/nlv07734, /home/nlv07749, /home/nlv07758, /home/nlv07785, /home/nlv14969, /home/nlv18676 26 - /home/beq03355, /home/dep08656, /home/nlv03675, /home/nlv03832, /home/nlv07317, /home/nlv07782, /home/nlv08789, /home/nlv11908, /home/nlv17216, /home/nxp09456 27 - /home/dep08620, /home/gbr02432, /home/nlv04130, /home/nlv06623, /home/nlv07776, /home/nlv07807, /home/nlv07836, /home/nlv14900, /home/nlv14944, /home/nxp09555, /home/nxp21031, /home/nxp25299 28 - /home/dep05228, /home/gbr02242, /home/nlv04120, /home/nlv04830, /home/nlv06090, /home/nlv07779, /home/nlv07824, /home/nlv08034, /home/nlv08131, /home/nlv08346, /home/nlv08964, /home/nlv14963, /home/nlv15815, /home/nlv20797 29 - /home/cdspip_cache 30 - /home/iosrc 31 - /home/keylink_scratch 32 - /home/hvsoilib 33 - /sysmnt/mail 34 - /home/cadmos34 35 - /home/hazelgrove 37 - /home/keylink 39 - /home/nlv05904, /home/nlv07031, /home/nlv07825, /home/nlv08120, /home/nlv08318, /home/nxp16612 44 - /sysmnt/cadappl_sde 47 - /home/audiopwr, /home/fagroup 51 - /home/ntas 51713 - /boot 64768 - / 64769 - /var 64770 - /mnt/spool, /tmp I have tested this with Samba 3.0.8, 3.3.8 and 3.4.4 - all contain the same code and have the same issue.
Created attachment 5375 [details] Test program that shows device for all mounted file systems
Created attachment 5376 [details] Test program with the sys_path_to_bdev from the Samba source Output: [root@inv0107 ~]# /home/nxp21031/test /home/nxp21031 st_dev = 27 (/home/nxp21031) -------------- st_dev = 64768 (/) st_dev = 3 (/proc) st_dev = 0 (/sys) st_dev = 11 (/dev/pts) st_dev = 64769 (/var) st_dev = 64770 (/mnt/spool) st_dev = 51713 (/boot) st_dev = 17 (/dev/shm) st_dev = 64770 (/tmp) st_dev = 18 (/proc/sys/fs/binfmt_misc) st_dev = 22 (/var/lib/nfs/rpc_pipefs) st_dev = 24 (/home/nlv07939) st_dev = 39 (/home/nlv05904) st_dev = 28 (/home/nlv08034) st_dev = 26 (/home/dep08656) st_dev = 27 (/home/nlv04130) Result: 0 mntpath: /home/nlv04130 bdev: nlnafvnxp34:/vol/fc_nxp34_b_us01/nxp01/nlv04130 fs: nfs
Created attachment 5377 [details] Work-around that works for us nxp21031@inv0107.nxdi.nl-cdc01$ ./test2 . st_dev = 23 (.) -------------- st_dev = 64768 (/) st_dev = 3 (/proc) st_dev = 0 (/sys) st_dev = 11 (/dev/pts) st_dev = 64769 (/var) st_dev = 64770 (/mnt/spool) st_dev = 51713 (/boot) st_dev = 17 (/dev/shm) st_dev = 64770 (/tmp) st_dev = 18 (/proc/sys/fs/binfmt_misc) st_dev = 22 (/var/lib/nfs/rpc_pipefs) st_dev = 24 (/home/nlv07939) st_dev = 30 (/home/iosrc) st_dev = 25 (/home/beq03399) st_dev = 39 (/home/dep08691) st_dev = 26 (/home/beq03355) st_dev = 29 (/home/keylink) st_dev = 28 (/home/nlv08034) st_dev = 39 (/home/nlv19952) st_dev = 23 (/home/nlv04130) st_dev = 23 (/home/nlv07776) st_dev = 23 (/home/nlv07807) st_dev = 23 (/home/nlv05948) st_dev = 25 (/home/nlv08193) st_dev = 26 (/home/nlv03832) st_dev = 37 (/home/amsnip_cache) st_dev = 39 (/home/nlv07748) st_dev = 28 (/home/nlv07762) st_dev = 23 (/home/nlv07657) st_dev = 27 (/home/ntas) st_dev = 24 (/home/nlv08101) st_dev = 39 (/home/nlv05904) st_dev = 28 (/home/nlv07779) st_dev = 23 (/home/nlv14944) st_dev = 25 (/home/nlv04156) st_dev = 39 (/home/nlv06099) st_dev = 24 (/home/nlv16740) st_dev = 26 (/home/nlv07317) st_dev = 23 (/home/nlv07836) st_dev = 39 (/home/nxp09459) st_dev = 24 (/home/nxp26812) st_dev = 39 (/home/nlv06088) st_dev = 28 (/home/nlv08955) st_dev = 23 (/home/nlv07805) st_dev = 26 (/home/nlv07016) st_dev = 40 (/home/hazelgrove) st_dev = 23 (/home/gbr01944) st_dev = 26 (/home/dep08656) st_dev = 28 (/home/dep05228) st_dev = 23 (/home/nlv06623) st_dev = 28 (/home/nlv04830) st_dev = 23 (/home/gbr03948) st_dev = 25 (/home/nlv07777) st_dev = 28 (/home/gbr02242) st_dev = 23 (/home/nxp25299) st_dev = 25 (/home/nlv07758) st_dev = 39 (/home/nlv04796) st_dev = 25 (/home/nlv08932) st_dev = 39 (/home/dep08637) st_dev = 39 (/home/nlv07991) st_dev = 28 (/home/nlv20797) st_dev = 23 (/home/nlv07349) st_dev = 39 (/home/nlv07825) st_dev = 39 (/home/nlv05901) st_dev = 44 (/home/devicephysics) st_dev = 28 (/home/nlv03935) st_dev = 25 (/home/nlv18676) st_dev = 26 (/home/nlv08789) st_dev = 23 (/home/nlv08127) st_dev = 23 (/home/nxp21031) Result: 0 mntpath: /home/nxp21031 bdev: nlnafvnxp34:/vol/fc_nxp34_b_us01/nxp01/nxp21031 fs: nfs nxp21031@inv0107.nxdi.nl-cdc01$ pwd /home/nxp21031
This seems to me to be a broken system. Samba *depends* on dev_t/inode pairs being unique for most of our functionality. I don't think this is a Samba bug, but an NFS server one. Re-assigning to Guenther for Red Hat avaluation. Jeremy.
I would say that's exactly the situation we have the "dfree command" parameter for. Volker
Yeah, but I think RH still needs to fix this with the NFS server. Non-unique dev/ino pairs will break all file serving functionality of Samba. User is just lucks so far that they haven't completely corrupted files :-). Jeremy.
I would guess that inodes are unique. I think the NFS server just passes through what it sees on disk. Volker
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb9120 "An inode is a data structure that defines a file, except for the filename which is stored in the directory entry. Note that a directory is just another file. The inode number is an integer unique to the volume upon which it is stored. Inodes point to blocks that make up a file, and inodes also contain the metadata of the file." So: The inode number is an integer unique to the -volume- upon which it is stored. As far as I can tell, only NFS mounts on the -same- volume seem to have the same dev_t on RHEL 5. So the combination of dev_t:ino_t would be uniquely identifying for a file (at least for files on the same physical filer).
RHEL 4 seems to allocate devices more or less sequentially. nxp21031@inv0107$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.2 (Tikanga) nxp21031@inv0107$ ls /home/nxp21031/.bashrc /home/nxp25299/.bashrc ls: /home/nxp25299/.bashrc: Permission denied /home/nxp21031/.bashrc nxp21031@inv0107$ ./test.pl|egrep '(nxp21031|nxp25299)' 27 - /home/atp01670, /home/dep08635, /home/gbr02432, /home/nlv04130, /home/nlv05948, /home/nlv05950, /home/nlv06565, /home/nlv06623, /home/nlv06869, /home/nlv07657, /home/nlv07711, /home/nlv07776, /home/nlv07786, /home/nlv07805, /home/nlv07836, /home/nlv08335, /home/nlv14944, /home/nxp21031, /home/nxp25299 nxp21031@acc3001$ cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 6) nxp21031@acc3001$ ls /home/nxp21031/.bashrc /home/nxp25299/.bashrc ls: /home/nxp25299/.bashrc: Permission denied /home/nxp21031/.bashrc nxp21031@acc3001$ ./test.pl|egrep '(nxp21031|nxp25299)' 24 - /home/nxp21031 30 - /home/nxp25299 test.pl is the script attached to this bug report.
Please use the "dfree command" (possibly together with "dfree cache time") workaround to hook into the query. This operation is pretty frequent, and to be fast for the normal case with statfs info being correct per device number, we don't want to fall back to string handling here. As we have a workaround for your situation already in place, closing this bug as "wontfix". Volker