SOLVED Only one user can connect to CIFS share

Status
Not open for further replies.

typoknig

Dabbler
Joined
Apr 13, 2013
Messages
16
1.) FreeNAS version and platform (32 or 64 bit).
FreeNAS-8.3.1-RELEASE-x64 (r13452)

2.) General hardware information (CPU, RAM, Motherboard model, etc.).
Everything contained in this Newegg wishlist.

3.) Specific hardware information (Network card chipset, Raid controller chipset, etc.).
See above.

4.) DMESG output or copy of specific error message.
No errors except the one Windows gives me that says "Location is not available".
1-png.2349



5.) IFCONFIG output if you are asking about a NIC or networking problem.
I'm not.

6.) PCICONF -lv output if you are asking about MotherBoard and / or PCI card problems.
I'm not.

Currently I have the following volume permissions. I have changed the Owner (user), Owner (group) and Mode settings many times and tried many combinations including nobody, nobody, 777, but regardless of the settings only I am able to connect to the CIFS share.
2-png.2350


Currently my CIFS settings look like this...
4-png.2352


and my CIFS share looks like this.
3-png.2351



I am the primary user of the system but I do have other users. The other users don't have/need a home directory, they just need read only access to some of my files via the CIFS share, and I want those users to have to type a password to access the share. One of my other users is named "media". Right now I have added "media" to the "typoknig" group. I would expect this would give "media" read only access to the volume but I only get the "Location is not available" error.

Any help would be appreciated.
 

Attachments

  • 1.png
    1.png
    5.7 KB · Views: 621
  • 2.png
    2.png
    13.2 KB · Views: 639
  • 3.png
    3.png
    17.2 KB · Views: 663
  • 4.png
    4.png
    294.4 KB · Views: 647
D

dlavigne

Guest
Does checking the execute bit on group and restarting the CIFS service fix it? You may have to also logout on the Windows size to clear the cached info.
 

typoknig

Dabbler
Joined
Apr 13, 2013
Messages
16
Does checking the execute bit on group and restarting the CIFS service fix it? You may have to also logout on the Windows size to clear the cached info.
No luck. Even if I have all nine permission bits checked (777) checked on the volume, assign the "typoknig" group to the auxiliary group of user "johndoe", restart FreeNAS, clear the cache of the Window client machine (by deleting all entries in net use), restart the client machine, and then try to connect to the share using the credentials of "johndoe" I get the Windows error I took a screen shot of. I have tried this with three different client computers too, using user names in FreeNAS that match the Windows user name (just to make sure).

Hell, I can even assign the "johndoe" user and group as the owner of the volume in addition to everything I mentioned above and "johndoe" STILL will not be able to connect to the share, even if "wheel" is in the auxiliary group of "johndoe" :(

I'm really at a loss here.
 

typoknig

Dabbler
Joined
Apr 13, 2013
Messages
16
No luck. Even if I have all nine permission bits checked (777) checked on the volume, assign the "typoknig" group to the auxiliary group of user "johndoe", restart FreeNAS, clear the cache of the Window client machine (by deleting all entries in net use), restart the client machine, and then try to connect to the share using the credentials of "johndoe" I get the Windows error I took a screen shot of. I have tried this with three different client computers too, using user names in FreeNAS that match the Windows user name (just to make sure).

Hell, I can even assign the "johndoe" user and group as the owner of the volume in addition to everything I mentioned above and "johndoe" STILL will not be able to connect to the share, even if "wheel" is in the auxiliary group of "johndoe" :(

I'm really at a loss here.


I finally figured out the problem. If folder "A" is shared via CIFS then the user accessing that CIFS share must have a permission path to folder "A" all the way from the root folder of the volume that folder "A" is contained in.

For my volume "tank" the owner was "root:wheel" and the permissions were 770. Inside the "tank" volume was a dataset called "storage" and the owner was "typoknig:storage" with 750 permissions. Inside the "storage" folder was a folder named "media" and the owner was "typoknig:media" with 750 permissions. I had two CIFS shares with this folder structure, one share was to the "storage" folder and the other was to the "media" folder which is contained inside the storage folder. I made the "media" share just to shield users who only cared about the media folder from the other stuff in the "storage" folder. So the folder hierarchy is:

tank > storage > media

With this setup user "john" with "media" in his auxiliary group cannot access the "media" CIFS share because he does not have permissions to access the "storage" folder, nor does he have permissions to access the "tank" folder. The solution then was change permissions on tank to 775 and then add "storage" to the auxiliary group for "john". Alternatively I could also just delete the storage group and set the owner of the "storage" folder to "root:wheel" with 775 permissions like the "tank" folder.

I haven't dealt with CIFS shares that much, but it seems ridiculous a user must have a permission path from the root of the volume all the way to the folder they want to access and actually have permissions for. Linus would not approve.
 

pirateghost

Unintelligible Geek
Joined
Feb 29, 2012
Messages
4,219
This is the way a windows share works. Linus has nothing to do with it.

Sent from my Galaxy Nexus
 
Status
Not open for further replies.
Top