DFS shares - can mount shared folder, but no access - error "object is remote"
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: Quote:
Quote:
This is just an update; still no solution. OP (ignoring the rantings of petulant children) |
Solved
OK, finally I have it. The answer is at http://lists.samba.org/archive/linux...ch/001854.html --
Quote:
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. |
Really not fixed
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 |
All times are GMT -5. The time now is 09:06 AM. |