Hi I am using Samba 2.0.6 on a SUN SPARC Solaris 2.6 machine. I compiled Samba using SUN cc with CFLAGS of "-fast". All the remaining configure parameters were left unspecified. I have been trying to use Samba to backup a nerwork of PCs onto the UNIX box. Each PC has a shared network drive, and the user issues an smbtar or smbclient backup command. eg. % smbclient //dcmbpc/C "" -N -d 0 -U backup -D "/" -TcXqa test.tar "" "Entertainment" "My Documents/My Music" "Export/Game Demo s" "Export/Unreal Tournament" "Windows/Win386.swp" "Win98" The backup itself seems to run without a problem. When I come to restore or list the tar file however, the long filenames get truncated. I have tried to list the tar with the SUN tar command and also restore it with smbtar and smbclient with no success. The output from a restore with smbclient is as follows: .... restore tar file \My Documents\Office Documents\Application Framework - Tracee\Design Flow Diagrams\Backup\v0.04\Wo of size 29683 bytes restore tar file \My Documents\Office Documents\Application Framework - Tracee\Design Flow Diagrams\Backup\v0.04\Wo of size 57389 bytes restore tar file \My Documents\Office Documents\Application Framework - Tracee\Design Flow Diagrams\Backup\v0.04\Wo of size 53524 bytes restore directory \My Documents\Office Documents\Application Framework - Tracee\Design Flow Diagrams\Backup\v0.04\rc restore directory \My Documents\Office Documents\Application Framework - Tracee\Design Flow Diagrams\New Folder\ restore directory \My Documents\Office Documents\Application Framework - Tracee\Design Flow Diagrams\New Folder\RCS\ abandoning restore Abandoning restore As you can see the filenames are truncatedto just "Wo". Also the restore aborts itself. The tar listing is as follows: -rw-r--r-- 0/0 65812 Jul 13 10:29 1999 ./My Documents/Office Documents/Application Framework - Tracee/Design Flow Diagrams/New Folder/Work ---------- 0/0 120 Jan 1 01:00 1970 ././@LongLink -rw-r--r-- 0/0 53177 Jul 7 16:55 1999 ./My Documents/Office Documents/Application Framework - Tracee/Design Flow Diagrams/Backup/v0.04/In ---------- 0/0 117 Jan 1 01:00 1970 ././@LongLink -rw-r--r-- 0/0 51694 Jul 7 16:56 1999 ./My Documents/Office Documents/Application Framework - Tracee/Design Flow Diagrams/Backup/v0.04/Re ---------- 0/0 120 Jan 1 01:00 1970 ././@LongLink -rw-r--r-- 0/0 57340 May 26 10:24 1999 ./My Documents/Office Documents/Application Framework - Tracee/Design Flow Diagrams/Backup/v0.04/Tr ---------- 0/0 130 Jan 1 01:00 1970 ././@LongLink -rw-r--r-- 0/0 65812 May 26 10:28 1999 ./My Documents/Office Documents/Application Framework - Tracee/Design Flow Diagrams/Backup/v0.04/Wo ---------- 0/0 122 Jan 1 01:00 1970 ././@LongLink -rw-r--r-- 0/0 29683 Jul 7 16:55 1999 ./My Documents/Office Documents/Application Framework - Tracee/Design Flow Diagrams/Backup/v0.04/Wo ---------- 0/0 121 Jan 1 01:00 1970 ././@LongLink The manual for smbtar states a limit of 1024 bytes for the filename and pathname. The filenames above do not exceed this limit, the number of bytes chopped off is only about 10-15 more. I would appreciate any suggestions as to why this might be happening. Cheers David. ----------------------------------------------------------------------------- | Image Processing & Interpretation | David Bilsby (Senior Engineer) | | email: d.bilsby@signal.dera.gov.uk | Defence Evaluation & Research Agency | | Tel: +44 (1684) 896158 | Room E306, St Andrews Road, | | Fax: +44 (1684) 894952 | Malvern, Worcs, WR14 3PS, ENGLAND | ----------------------------------------------------------------------------- The Information contained in this e-mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the intended recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. The views expressed herein are entirely those of the author and do not represent the views, policy or understanding of any other person or official body.
Samba does not use NFS. It uses TCPIP with netbios. This is the same protocol that microsoft uses for lan manager (file sharing) with tcpip. -- Sol Gongola (sol@adldata.com) ADL Data Systems Inc 20 livingstone ave Dobbs Ferry, NY 10522
don_mccall@hp.com
2000-Apr-07 16:16 UTC
To Bart re user on passwd server but not local server
Hello Bartlomiej, This is not a bug, but a requirement for Samba. Samba MUST have a unix user uid and gid on the system where it is executing to determine what access to give to the unix files. The password server option merely goes to the password server in question and verifies that the username and password are authentic. It must STILL be able to map that username to a local UNIX user in etc/passwd or the nis database. OR alternatively you can use the user map file to map the username to a DIFFERENT UNIX user that exists. Hope this helps, Don
Hi Henry; This error typically means that the password you are using for the username has expired; smbclient has no way to allow you to change it, so you would need to login to this server with an nt or win9x client to get the message saying your password has expired, and change it then. Just a guess, Don
[David C. M. Bilsby]> The backup itself seems to run without a problem. When I come to > restore or list the tar file however, the long filenames get > truncated. I have tried to list the tar with the SUN tar command and > also restore it with smbtar and smbclient with no success.The standard "tar file" format is kind of weird. IIRC, the pathname is stored in two separate strings, each of which has a max length (99 characters for one of them, I believe). Something like: more pathname component(s) pathname component(s) go here and filename go here +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So to use the absolute maximum length, your pathname must have a separator in *exactly* the right place.> The manual for smbtar states a limit of 1024 bytes for the filename > and pathname. The filenames above do not exceed this limit, the > number of bytes chopped off is only about 10-15 more.Hmmmm, I thought the limit was *considerably* lower.> I would appreciate any suggestions as to why this might be happening.Well, try this. Create an identical directory tree under Unix (just one branch will do for the test), and tar it up. See if *that* works. If so, it's a smbclient bug; if not, it's a limitation of the tarfile format. Peter