I need to access shared folders in DFS on a Windows network, using my Linux machine. I have been able to mount the shared folder on my file system with a command like this -

mount -t smbfs '//157.147.76.153/dfs/' -o user='domain\username' mnt

I can then list the top level directories, but can see nothing inside them....

$ ls mnt
Applications Common Albatross Something Projects Else
$ ls mnt/Projects
ls: reading directory mnt/Projects: Object is remote

So this is useless.

BUT... I can access the directories with smbclient....

smbclient '\\157.147.76.153\dfs\Projects\Foo' [password] -U 'domain\username'

Now I have a prompt, can cd, ls and see all the files, and I can get and put them - but of course I cannot open them in applications running on my Linux system. I have to copy them to my local file system and open them from there, and copy the modified version back. Quite a pain...

So -- now for my questions...

1. What does it mean - object is remote? Of course it's remote - it's on another machine! That's rather the point, isn't it?
2. Is there a way to mount this thing so I can use the files directly?
3. Is there an application which has a convenient GUI plus smbclient functionality so I can make my life easier if I cannot access files directly?
4. Why can smbclient read a dfs filesystem, when other methods fail?

Please help if you can!

When I googled this, your question was the first hit. So it's not a problem, it's configuration. Samba will surely only be granted luser permissions by the remote system. Check things

1. Have you execution permissions on the directory?
Try this on some non empty subdir in your home directory
chmod -x <subdir>
ls -l <subdir>

2. Have you tied your own shoelaces together in smb.conf? I suffered with that. All sorts of guys put up their 'fully working' smb.conf and samba got all petulabnt nasty or went on strike.

3. Stop Samba. Try to restart it in debug mode and see what the issue is. The windoze box will/should have logs also.

1. Have you execution permissions on the directory?
Try this on some non empty subdir in your home directory
chmod -x <subdir>
ls -l <subdir>

What does access to local directories have to do with my problem accessing a remote share? All permissions are set on the host.

2. Have you tied your own shoelaces together in smb.conf? I suffered with that. All sorts of guys put up their 'fully working' smb.conf and samba got all petulabnt nasty or went on strike.

smb.conf has nothing to do with my access to remote shares as a client.
...and I wear sandals

3. Stop Samba. Try to restart it in debug mode and see what the issue is. The windoze box will/should have logs also.

What do you mean by "samba"? There is no program by that name. Do you mean the daemons smbd and nmbd? It is not necessary to run those in order to mount remote shares to which one has been given access. They are only needed to run a samba server.

Perhaps I was not clear -- I am not trying to share anything on my local filesystem; I only have need to access a dfs server on the network.

I have googled extensively and have found what seems to be evidence from old posts on mailing lists that access to dfs shares with smb.mount is problematic at best. Perhaps access with smbclient is the best I can do. I had hoped that the state of things had improved; surely it cannot be so uncommon that a Linux client needs access via LAN to these DFS shares - can it? I understand that client-side software is required for this, and that it is included in smbclient - which is why that program works with dfs - but that there are problems implementing it when mounting the shares on the local system, rather than just implementing a transfer protocol. This seems to a rather big impediment to universal Linux adoption, I would think, as DFS seems to be getting more and more common. At the moment I am getting around the problem by running windoze expee in a virtual machine in order to access the files I need. This works, but it's not an elegant method - and it's not Linux!

I tell you what you do.

Why don't you post for help and shoot down whoever tries to help you and see how far you get. I am not bothered correcting you if you don't see the points I was trying to establish. Of course no executable samba exists, but most distros carry an rc.d script of that name which is executable, etc. etc.

Don't try to help this guy - he will shoot you down.

It took a lot of googling to find this, but I have confirmation that I am not alone with this problem; see

http://www.linux-archive.org/debian-...ct-remote.html

Or, to quote from the question:

and the answer:

I found that I did not even have the program cifs.upcall on my system. Ahah, I thought, maybe that's the problem. I had to compile the entire samba code with the right configure options turned on just to get a binary of cifs.upcall, and then I did exactly as the above instructions describe. My cifs.upcall works; I did a ldd on it and it has all the libs it needs. But I still cannot read the directories of my already mounted DFS share -- I still get the dreaded "object is remote". Grrr.

This is just an update; still no solution.
OP (ignoring the rantings of petulant children)

OK, finally I have it. The answer is at http://lists.samba.org/archive/linux...ch/001854.html --

YES!!! It works!!!

I bypassed the dfs, and did this --
mount.cifs //157.147.76.153/Projects$ mnt -o username='<domain>\<user>' //

-- entered my password, and now I have direct access to all the files.

I sure hope this helps someone, someday.

The last post from gbloon gave us a work around but not a true solution.

I work in a large IT company and have DFS file shares everywhere. To solve my problem, I would need to mount a few different server/share devices to get to all the data I need.

This thread exactly describes the problem I am having.
Does anyone have a solution to accessing DFS shares using a command like
mount.cifs -o credentials=<fname> //<servername>/<sharename> /mnt/dfsshare