Bug 9772 - Can't access Samba Share from DOS-Client
Summary: Can't access Samba Share from DOS-Client
Status: RESOLVED DUPLICATE of bug 2662
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.6.13
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-08 14:56 UTC by Conrad Kostecki
Modified: 2013-04-08 20:57 UTC (History)
1 user (show)

See Also:


Attachments
smb.conf (1011 bytes, application/octet-stream)
2013-04-08 14:57 UTC, Conrad Kostecki
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Conrad Kostecki 2013-04-08 14:56:38 UTC
Hi!
I am using Samba, to enable a share which can be access under \\galactica\pxe in my local network.

Linux and Windows can access this share without any problems.
But I need this share to be accessed from DOS. And this is not working :/

I can "mount" this share under DOS with:
net use z: \\galactica\pxe

This works. But now, when I want to access this share, a loop happens. For example, I enter z: and then want to show all files with "dir", the loop is starting output like:

DIRNAME
DIRNAME
DIRNAME
DIRNAME
DIRNAME
...

Its going forever. I have to abort this with CTRL+C. And its only showing the first directory in there. When I try to execute some file, it just hangs. I've tested several dos clients to access samba. All clients fail the same way, to there seems to be a problem with samba and legacy access?

My System:
Gentoo Linux Kernel 3.8.4-gentoo
net-fs/samba-3.6.13  USE="aio readline server -acl -addns -ads -avahi -caps -client -cluster -cups -debug -dmapi -doc -examples -fam -ldap -ldb -netapi -pam -quota (-selinux) -smbclient -smbsharemodes -swat -syslog -winbind"

I will attach my smb.conf
Comment 1 Conrad Kostecki 2013-04-08 14:57:26 UTC
Created attachment 8736 [details]
smb.conf
Comment 2 Jeremy Allison 2013-04-08 16:13:39 UTC
This is a duplicate. It's a known bug with 64-bit directory offsets. It simply doesn't work for now. You could try running the DOS application in a Windows DOS box.

I'll merge this bug with the other outstanding one.

Jeremy.
Comment 3 Conrad Kostecki 2013-04-08 20:39:56 UTC
(In reply to comment #2)
> This is a duplicate. It's a known bug with 64-bit directory offsets. It simply
> doesn't work for now. You could try running the DOS application in a Windows
> DOS box.
This is no alternative for me. I am using DOS-Boot via PXE. Are there any possible workarounds?

> I'll merge this bug with the other outstanding one.
Is it considered, that this will be fixed? Or WONTFIX?

Conrad
Comment 4 Conrad Kostecki 2013-04-08 20:50:07 UTC
Found the correct bug.

*** This bug has been marked as a duplicate of bug 2662 ***
Comment 5 Jeremy Allison 2013-04-08 20:54:46 UTC
It's not WONTFIX, but it's low priority as few people need DOS clients or are in your situation.

The only workaround I can think of is try an older filesystem such as ext3 which may still use an index offset rather than a 64-bit cookie for the telldir() return value.
Comment 6 Conrad Kostecki 2013-04-08 20:57:38 UTC
(In reply to comment #5)
> It's not WONTFIX, but it's low priority as few people need DOS clients or are
> in your situation.

I'am glad to hear! :) I understand absolutely, that DOS clients aren't any priority.

> The only workaround I can think of is try an older filesystem such as ext3
> which may still use an index offset rather than a 64-bit cookie for the
> telldir() return value.

At least, disabling dir_index on ext4 worked.
Does this problem also occur, when using fat16/fat32 for a dos share? A fne solution for me would be a separated partition with another file system (in fact, its already a separate one, but with ext4)