SMB File Name Not Valid or Too Long

[julesq]

I'm encountering some odd behavior on SMB file shares.

On about a third of the files on my share, if I try to open them or copy them over to my local Windows machine, I get an error that says "The file name you specified is not valid or too long. Specify a different file name." I've enabled long file names in the Windows group policy, but the full file path is still < 60 characters. Changing the file name doesn't work. Other files in the same directory (some with longer names) transfer/open fine. Transfers over WebDAV or FTP work fine. Zipping the file on the network drive and then copying the zip file over and then unzipping also works fine. Can't seem to find a rhyme or reason to which ones won't transfer over SMB.

This is a new issue, SMB worked perfectly fine before. I recently upgraded FreeNAS to 11.3-U1. This is also a new Windows 10 install (running 1909), installed around the same time as the FreeNAS upgrade, so I don't know if it's an issue with the Windows install or with the FreeNAS upgrade.

 

[anodos]

I'm encountering some odd behavior on SMB file shares.

On about a third of the files on my share, if I try to open them or copy them over to my local Windows machine, I get an error that says "The file name you specified is not valid or too long. Specify a different file name." I've enabled long file names in the Windows group policy, but the full file path is still < 60 characters. Changing the file name doesn't work. Other files in the same directory (some with longer names) transfer/open fine. Transfers over WebDAV or FTP work fine. Zipping the file on the network drive and then copying the zip file over and then unzipping also works fine. Can't seem to find a rhyme or reason to which ones won't transfer over SMB.

This is a new issue, SMB worked perfectly fine before. I recently upgraded FreeNAS to 11.3-U1. This is also a new Windows 10 install (running 1909), installed around the same time as the FreeNAS upgrade, so I don't know if it's an issue with the Windows install or with the FreeNAS upgrade.

Can you PM me a debug (system->advanced->save debug)?

 

[deadmanIsARabbit]

@julesq i got the same problem after upgrading fot 11.3-U1. I am running several Windows clients, all of them didn't have this issue before the upgrade. I would guess it is FreeNAS related.

@anodos i will PM you a debug as well, if this is okay for you?

 

[deadmanIsARabbit]

Strange behaviour: This will only happen with the windows explorer. Copying with TeraCopy won't produce this error.

 

[anodos]

Strange behaviour: This will only happen with the windows explorer. Copying with TeraCopy won't produce this error.

Yes, PM me the debug.

 

[Turtle3000]

I am also experiencing this issue after upgrading to 11.3-U1, and I am also on Windows version 1909. I am able to overcome this by moving the file to a folder with a shorter path then retrying the copy operation.

 

[Turtle3000]

I am also experiencing this issue after upgrading to 11.3-U1, and I am also on Windows version 1909. I am able to overcome this by moving the file to a folder with a shorter path then retrying the copy operation.

To add to this, I have confirmed that when booting 11.2-U8 and the issue is not prevalent.

 

[curvingedge]

I am having this same problem. Is there a solution? It seems to happen to me with large file sizes >1gb. I have tried booting back to 11.2, but didn't fix the problem. I did recently upgrade the pool. My suspicion is this caused the issue. I had no problems transferring large files over SMB previously.

 

[curvingedge]

I am having this same problem. Is there a solution? It seems to happen to me with large file sizes >1gb. I have tried booting back to 11.2, but didn't fix the problem. I did recently upgrade the pool. My suspicion is this caused the issue. I had no problems transferring large files over SMB previously.

I've tested large file transfers from Synology and it works fine. Seems to be a FreeNAS problem.

 

[curvingedge]

I've tested large file transfers from Synology and it works fine. Seems to be a FreeNAS problem.

So I moved the same file off the root pool into a dataset and transfers work fine.

 

[curvingedge]

Sorry for all the back to back posts. I am troubleshooting and keep finding more info. And now I'm relieved to report I have fixed my problem. I needed to delete the SMB share and re-add it. Now it's working again.

 

[Turtle3000]

Sorry for all the back to back posts. I am troubleshooting and keep finding more info. And now I'm relieved to report I have fixed my problem. I needed to delete the SMB share and re-add it. Now it's working again.

It's 100% a freenas and Windows compatibility issue. Powershell and explorer both have the same behavior, not sure if I tried robocopy or xcopy. But as a workaround when I am working really deep in my directory structure I use TeraCopy like @deadmanIsARabbit mentioned above. If you find a real solution please let me know.

I think the proper thing to do is create a Jira ticket with the details, there might already be one.

 

[Turtle3000]

Wow thank you for posting the fix. I probably should've read the quoted text before actually posting the reply and mentioning that person.

Apologies, I probably should be drinking and commenting on the freenas forums

 

[anodos]

What is output of "testparm -s"?

 

[gwur]

I get this error too.

FreeNAS-11.3-U4.1
FreeBSD freenas.local 11.3-RELEASE-p11

Here is the output of my testparm -s

freenas% testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

# Global parameters
[global]
aio max threads = 2
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
enable web service discovery = Yes
kernel change notify = No
load printers = No
logging = file
max log size = 51200
nsupdate command = /usr/local/bin/samba-nsupdate -g
restrict anonymous = 2
server min protocol = SMB2_02
server role = standalone server
server string = FreeNAS Server
unix extensions = No
username map = /usr/local/etc/smbusername.map
username map cache time = 60
idmap config *: range = 90000001-100000000
idmap config * : backend = tdb
allocation roundup size = 0
directory name cache size = 0
dos filemode = Yes
include = /usr/local/etc/smb4_share.conf

[Main Storage]
aio write size = 0
ea support = No
mangled names = illegal
path = /mnt/XXX/YYY
read only = No
vfs objects = fruit streams_xattr zfs_space zfsacl
nfs4:acedup = merge
nfs4:chown = true
fruit:resource = stream
fruit:metadata = stream
streams_xattr:store_stream_type = no
streams_xattr:prefix = user.
fruit:locking = netatalk

 

[anodos]

Try setting auxiliary parameters:

Code:

streams_xattr:store_stream_type = yes
streams_xattr:prefix = user.DosStream.

 

[gwur]

Try setting auxiliary parameters:

Code:

streams_xattr:store_stream_type = yes
streams_xattr:prefix = "user.DosStream."

Thanks. I put that in to Samba Advanced Mode Edit Auxiliary Parameters. Confirmed it was in place via testparm -s. Tried the copy and it failed with the same error. Turned off SMB service via web interface, confirmed it was off. Started SMB service. Tried the copy and the copy worked.

Is this something that should be part of default settings?

 

[anodos]

Thanks. I put that in to Samba Advanced Mode Edit Auxiliary Parameters. Confirmed it was in place via testparm -s. Tried the copy and it failed with the same error. Turned off SMB service via web interface, confirmed it was off. Started SMB service. Tried the copy and the copy worked.

Is this something that should be part of default settings?

No. This is an issue because your share is also an AFP share. We need to make sure that data is being written / read in the same way through both Netatalk and Samba. I gave you the default setting for a non-mixed-protocol share. I'm making multiple xattr-related fixes for 11.3-U5 and later that should address this problem.

 

[tazman69er]

No. This is an issue because your share is also an AFP share. We need to make sure that data is being written / read in the same way through both Netatalk and Samba. I gave you the default setting for a non-mixed-protocol share. I'm making multiple xattr-related fixes for 11.3-U5 and later that should address this problem.

I have the same problem that everyone else reports and I tried adding in aux parameters per above by going to Services-->SMB-->Edit and adding the lines above in the aux. parameters bucket. I then tried stopping and restarting SMB service and I'm still seeing the same problem... See Attached screen shots of where I added the aux. parameters. I am running on 11.3-RELEASE and am also running a 'mixed mode' share as that is the only way my mac seemed to be able to see the SMB share.

Here's my params after making above change:

root@MyServer[~]# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

# Global parameters
[global]
aio max threads = 2
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
enable web service discovery = Yes
kernel change notify = No
load printers = No
logging = file
max log size = 51200
nsupdate command = /usr/local/bin/samba-nsupdate -g
restrict anonymous = 2
server min protocol = SMB2_02
server role = standalone server
server string = FreeNAS Server
unix extensions = No
username map = /usr/local/etc/smbusername.map
username map cache time = 60
streams_xattr:prefix = user.DosStream.
streams_xattr:store_stream_type = yes
idmap config *: range = 90000001-100000000
idmap config * : backend = tdb
allocation roundup size = 0
directory name cache size = 0
dos filemode = Yes
include = /usr/local/etc/smb4_share.conf

[BigTazNAS]
aio write size = 0
ea support = No
mangled names = illegal
path = /mnt/My Mount Point
read only = No
vfs objects = ixnas fruit streams_xattr
nfs4:acedup = merge
nfs4:chown = true
fruit:resource = stream
fruit:metadata = stream
streams_xattr:store_stream_type = no
streams_xattr:prefix = user.
fruit:locking = netatalk

 

[anodos]

You stuck the aux params in the wrong place (should be share level). What version of FN is this?