Cannot connect to 1 out of 2 CIFS shares

[LastRogue]

This is for a simple home project I am working on, nothing business class.

I am running FreeNAS-9.3-STABLE-201512121950

My system has 4 GB of RAM and is on a AMD64 architecture.

I have two CIFS shares on two separate drives.

The first one I created was accessible after some troubleshooting permission issues where I noticed messages in in the log. This working share is on a 300GB drive

On the second share I am getting the below messages in the log when trying to access them from a windows client. The share is on a 1 TB drive

Message log snippet:

Dec 23 12:15:19 freenas smbd[3675]: [2015/12/23 12:15:19.219256, 0] ../lib/util/modules.c:48(load_module)
Dec 23 12:15:19 freenas smbd[3675]: Error loading module '/usr/local/lib/shared-modules/vfs/r.so': Cannot open "/usr/local/lib/shared-modules/vfs/r.so"
Dec 23 12:15:19 freenas smbd[3675]: [2015/12/23 12:15:19.219415, 0] ../source3/smbd/vfs.c:184(vfs_init_custom)
Dec 23 12:15:19 freenas smbd[3675]: error probing vfs module 'r': NT_STATUS_UNSUCCESSFUL
Dec 23 12:15:19 freenas smbd[3675]: [2015/12/23 12:15:19.219487, 0] ../source3/smbd/vfs.c:349(smbd_vfs_init)
Dec 23 12:15:19 freenas smbd[3675]: smbd_vfs_init: vfs_init_custom failed for r
Dec 23 12:15:19 freenas smbd[3675]: [2015/12/23 12:15:19.219633, 0] ../source3/smbd/service.c:640(make_connection_snum)
Dec 23 12:15:19 freenas smbd[3675]: vfs_init failed for service share02


Looking in the directory that the module path points to, I do not see 'r.so'.

Things I have tried so far:

- Wiping, re-mounting, re-partitioning, and recreating the share and datasets.
- Mirroring permissions from the working share.
- Allowing guest access.
- Restarting CIFS service
- Rebooting

Would anyone here have any suggestions on where to start with this? Is there any other information needed that I should provide?

 

[anodos]

Post contents of /etc/local/smb4.conf

 

[LastRogue]

Thanks for the reply.

Here is the contents of the smb4.conf:

[global]
server max protocol = SMB2
encrypt passwords = yes
dns proxy = no
strict locking = no
oplocks = yes
deadtime = 15
max log size = 51200
max open files = 117182
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
getwd cache = yes
guest account = nobody
map to guest = Bad User
obey pam restrictions = yes
directory name cache size = 0
kernel change notify = no
panic action = /usr/local/libexec/samba/samba-backtrace
nsupdate command = /usr/local/bin/samba-nsupdate -g
server string = FreeNAS Server
ea support = yes
store dos attributes = yes
lm announce = yes
hostname lookups = yes
time server = yes
acl allow execute always = true
acl check permissions = true
dos filemode = yes
multicast dns register = yes
domain logons = no
local master = yes
idmap config *: backend = tdb
idmap config *: range = 90000001-100000000
server role = standalone
netbios name = FREENAS
workgroup = WORKGROUP
security = user
pid directory = /var/run/samba
create mask = 0666
directory mask = 0777
client ntlmv2 auth = yes
dos charset = CP437
unix charset = UTF-8
log level = 1


[media-share]
path = /mnt/share02/media-share
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
vfs objects = zfs_space zfsacl a i o _ p t h r e a d s t r e a m s _ x a t t r
hide dot files = yes
guest ok = yes
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare


[share01]
path = /mnt/share01/share01
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
vfs objects = zfs_space zfsacl
hide dot files = yes
guest ok = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare





EDIT: The share01 is the share that is working, media-share is not.

 

[gpsguy]

Do note that you only have 1/2 of the minimum RAM required for FreeNAS.


Sent from my phone

 

[LastRogue]

Do note that you only have 1/2 of the minimum RAM required for FreeNAS.


Sent from my phone

Indeed, that's why I mentioned it in the original post. I wouldn't think that would attribute to this, but I understand it isn't outside the realm of possibility.

The error points to not being able to open 'r.so' and 'r.so' not existing is where I thought I should be looking. But I don't know where to go from there.

Am I going down the wrong trail here?

EDIT1: The system I'm running on can only support 4 GB of RAM. That said, should I be using something like this instead?:

FreeNAS-9.2.1.9-RELEASE-x86


EDIT2: I thought I would check the Memory and CPU usage to confirm that CPU and RAM aren't maxing out and they all look to be in reasonable ranges (hardly anything being used):


42 processes: 1 running, 41 sleeping
CPU: 0.0% user, 0.0% nice, 0.2% system, 0.2% interrupt, 99.6% idle
Mem: 397M Active, 108M Inact, 344M Wired, 4416K Cache, 3066M Free
ARC: 148M Total, 40M MFU, 97M MRU, 48K Anon, 1417K Header, 8988K Other
Swap: 4096M Total, 4096M Free

 

[solarisguy]

Maybe?

• stop CIFS
• make vfs objects line for media-share like the one for share01 (at first, try doing that in the GUI)
• start CIFS

 

[LastRogue]

Okay, I totally just fixed it.

Thanks to Anodos for pointing me to the smb4.conf.

Solarisguy, you were on the right track there. You posted just as I was replying here.

I noticed it was broken up and probably that the error was seeing r.so as the last line of xattr having spaces in it.

I tried it through SSH first, it just replaced the line again.

I added the same parameters through the GUI and it re-formatted the line in the conf file. I removed the paremeters and it matches share01's vfs objects line.

Thanks for the help!

 

[solarisguy]

@LastRogue, are you saying that after you added parameters aio_pthread and streams_xattr in the GUI, the corresponding entry in smb4.conf is mangled ?

 

[LastRogue]

@LastRogue, are you saying that after you added parameters aio_pthread and streams_xattr in the GUI, the corresponding entry in smb4.conf is mangled ?

They were there in the conf file and mangled every time I recreated the share from the first time all through the wiping the drive and re-creating it. I never added them prior to my last step in troubleshooting.

Looking through the GUI they were not actually present. So I added them to the share in the GUI, saved it and made sure the conf file was not mangled. It looked fine so I removed those values through the GUI and saved it.

After removing the values again it matched share01 and was not mangled, so to speak, anymore.

 

[solarisguy]

Thank you! I was just trying to understand where in FreeNAS the bug is. Maybe someone will follow up and be able to recreate the condition on a test system, as I think it warrants an investigation (yes, it could be due to only 4GB of RAM, but may be not)

 

[LastRogue]

No problem. Thanks to all on figuring this out as well!

 

[SweetAndLow]

If you want to run 4GB of memory 9.2.x.x still isn't going to work. That version still requires 8GB to be predictable. 9.1 might work with 4GB.

 

[solarisguy]

If you want to run 4GB of memory 9.2.x.x still isn't going to work. That version still requires 8GB to be predictable. 9.1 might work with 4GB.

UFS vs. ZFS, but also I do not think the error seen can be easily dismissed as due to 4GB RAM only.

 

[Foosman]

Thanks for sharing above. I encountered this same issue on a new install using FreeNAS-9.3-STABLE-201512121950.
I am using 8GB of RAM.
For anyone else who encounters this error:
1) Check /etc/local/smb4.conf
If you see mangled parameters, these can be fixed in:
Sharing -> Widows (CIFS) -> Double click on share with the problem -> Advanced Mode
under VFS Object add:
aio_pthread
streams_xattr

Now I'm chasing down another error "Failed to fetch record!". Samba seems quite buggy on FreeNAS.

 

[BackwardsCire]

This is timely. I had the same issue and Foosman's instructions worked great.

Brand new build of FreeNAS earlier in the week using latest nightly. AFP shares worked great but CIFS would result in being able to see the shares from windows, but clicking on the share resulted in “Windows cannot access \\FREENAS” Check the spelling of the name . Otherwise there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.” error. All other troubleshooting threads discussed trying to get to the share via \\ip\sharename but that did not work.

I know that i'm a FreeNAS noob, but I'm glad to know that I'm not losing my mind.

Has an official bug been filed yet?

 

[anodos]

This is timely. I had the same issue and Foosman's instructions worked great.

Brand new build of FreeNAS earlier in the week using latest nightly. AFP shares worked great but CIFS would result in being able to see the shares from windows, but clicking on the share resulted in “Windows cannot access //FREENAS” Check the spelling of the name . Otherwise there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.” error. All other troubleshooting threads discussed trying to get to the share via //ip/sharename but that did not work.

I know that i'm a FreeNAS noob, but I'm glad to know that I'm not losing my mind.

Has an official bug been filed yet?

Those should be backslashes not forward slashes.

 

[BackwardsCire]

Right, sorry. That is what I was using. Posted quickly. Edited post to reflect.

 

[Foosman]

Has an official bug been filed yet?

I haven't submitted a bug, I'll submit one this week for sure.

 

[Grogdor]

Wizard creates broken CIFS shares #13361 - delete the share and re-create it manually.

 

[johnfv]

Thanks for posting the bug and workaround. I'm setting up my 2nd freenas server (a "real" one: supermicro MB, 16GB ECC RAM, etc.) and used the wizard to setup the share. Could not connect to share from Windows 7 (times out). Spent a lot of time head scratching and comparing to my other server that works. Saw this bug post, deleted the share, created manually and now connects fine.