2

I have a directory that is shared via samba. Now I mount a share on another computer to a directory that is inside this share. The problem is that this mounted share appears as empty directory when accessing the share.

Does anyone know why this happens or how one would correctly be able to access another computer's share as if it were part of another share?

Added example:

If it helps, here is how such a scenario can be created:

# on host assume that we are `user1`
# assume that we use `[homes]` in `smb.conf` so our home directory is shared
mkdir -p d1/d2 && cd d1
# assume that there is a `host2`
# with a share named `share2` and a user `user2`
sudo mount.cifs -o username=user2 '//host2/share2' d2
# we check and see that it works and files from `share2` are visible
ls d2
# now we try to use this share from anywhere, for example locally
echo "ls d1/d2" | smbclient '\\localhost\user1' -U user1
# now we will only see an empty directory
user579825
  • 101
  • 8
  • It is unclear what you are trying to share and where. Please clarify your question and show what commands you have used on which machines. – AFH Jun 13 '16 at 12:27
  • I purposely phrased it in this general way because it did not matter how I created a nested mount in a samba share. But I added it back as example for clarity as commands may be easier to understand than a description. – user579825 Jun 13 '16 at 12:57
  • Thanks for the clarification: it's not what I though you were trying to do. I am looking at the problem, but it is difficult for me to set up a test. – AFH Jun 13 '16 at 13:10
  • Actually, I have figured something out while doing it. It seems that smbclient does not work as I expected; if I type "ls dir", I do not seem to be able to see the contents. I have to cd and then use ls. However, I get an permission error if I try to access the .gvfs directory, which was the original origin of why I began investigating. Is there any reason why this is different or how one would be able to access automatically mounted shares in .gvfs? Probably something related to security. – user579825 Jun 13 '16 at 13:14
  • I think it is a security issue: I haven't analysed it fully yet, but it looks as though the user name for accessing `share2` is not accessible when accessing `share1` as `user1`. However, this is not a complete explanation, and I am investigating further. – AFH Jun 13 '16 at 13:27
  • It gets extremely weird for me: I added a Windows 10 client to the mix for testing. I can see and open files in text editors, but I cannot open files with video players such as mpc, I always get "file not found". – user579825 Jun 13 '16 at 13:42
  • Oh and while browsing, it seems that a subdirectory looks like a file. – user579825 Jun 13 '16 at 13:49
  • 1
    I haven't managed to find out how mount point data are stored, but [this answer](http://superuser.com/questions/200685/what-does-linux-do-with-existing-files-in-a-mount-point/200697#200697) shows how mount points can be bypassed, and I think your example is working similarly. The mount points are stored in `/etc/mtab` (linked to `proc/mount` in Debian and derivatives), but I wouldn't expect every directory access to check this file, even if it is mirrored or indexed in memory, though maybe it does. – AFH Jun 14 '16 at 12:50

1 Answers1

1

After investigating, it seems I have been affected by a bug as described here: https://serverfault.com/questions/491464/directories-shown-as-files-when-sharing-a-mounted-cifs-drive

It seems there is a bug when "resharing" with samba: Directories are shown as files because of a bug. Samba uses the inode count to determine this and cifs sets this to zero. So all directories appear as files of size zero.

The proposed solution is to recompile a kernel module for samba, but I do not think that is a viable solution. It has been 3 years since the answer, maybe someone knows a better solution now. The original bug has been marked as WILL_NOT_FIX in cifs and in samba, nothing seems to have happened.

If anyone has a better solution, I would like to hear from them.

user579825
  • 101
  • 8