SMB share has folders that are invisible - FIXED

Status
Not open for further replies.

Craash

Cadet
Joined
Jul 24, 2017
Messages
5
My Config is in my signature.

My NAS is ONLY used for FAST 2nd copy backup. It's accessed by multiple machines (virtual and physical) by both NFS and SMB. These are primarily Ubuntu 16.x/17.x and Windows 10.

I have a nfs export of /mnt/Volume.1/media (lowercase 'media')

A Ubuntu 17.x server mounts that NFS and using rsysnc creates a mirror of it's media folder. So the immediate directory under /mnt/Volume.1/media ends up with folders for Movies, Music, Sports, Television and a few others.

The NAS also has a SMB share of /mnt/Volume.1/media shared as Media (uppercase 'Media').

All of my machines use one primary local account for normal activity. Let's say "support". This same account (and group) exists on the freeNAS. The password for "support" is the same on all machines.

The ISSUE.
When I browse to the Media SMB share on the freenas with a windows 10 client, I only see a few of the root folders. For example, right now I have file explorer open to \\freenas\media and I don't see a "Movies" folder. Now, I can add "Movies" to the address bar (\freenas\media\Movies) and bingo, I see all the sub directories without having to type in the full path. I then also have full RWX access. So it only happens at that one level.

If I map \\freenas\media to a drive on a windows 10 client, a command prompt "DIR" doesn't show the Movies folder. A DIR /a DOES show them. Which indicates it's hidden, but I can't for the life of me figure out how to fix it.

Turning on hidden folders doesn't make a difference. I've Chown'd from the Ubuntu, I've set permission recursively via FreeNAS to User and Group "support". No Love.

I did find a blurb about removing the execute perm from the "other" group, but this didn't make a difference.

There are two other exports/shares on this NAS setup in the same manner and neither of those have this issue.

Thoughts?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
My Config is in my signature.

My NAS is ONLY used for FAST 2nd copy backup. It's accessed by multiple machines (virtual and physical) by both NFS and SMB. These are primarily Ubuntu 16.x/17.x and Windows 10.

I have a nfs export of /mnt/Volume.1/media (lowercase 'media')

A Ubuntu 17.x server mounts that NFS and using rsysnc creates a mirror of it's media folder. So the immediate directory under /mnt/Volume.1/media ends up with folders for Movies, Music, Sports, Television and a few others.

The NAS also has a SMB share of /mnt/Volume.1/media shared as Media (uppercase 'Media').

All of my machines use one primary local account for normal activity. Let's say "support". This same account (and group) exists on the freeNAS. The password for "support" is the same on all machines.

The ISSUE.
When I browse to the Media SMB share on the freenas with a windows 10 client, I only see a few of the root folders. For example, right now I have file explorer open to \\freenas\media and I don't see a "Movies" folder. Now, I can add "Movies" to the address bar (\freenas\media\Movies) and bingo, I see all the sub directories without having to type in the full path. I then also have full RWX access. So it only happens at that one level.

If I map \\freenas\media to a drive on a windows 10 client, a command prompt "DIR" doesn't show the Movies folder. A DIR /a DOES show them. Which indicates it's hidden, but I can't for the life of me figure out how to fix it.

Turning on hidden folders doesn't make a difference. I've Chown'd from the Ubuntu, I've set permission recursively via FreeNAS to User and Group "support". No Love.

I did find a blurb about removing the execute perm from the "other" group, but this didn't make a difference.

There are two other exports/shares on this NAS setup in the same manner and neither of those have this issue.

Thoughts?

Post following enclosed in [ code ] tags:
  • Contents of /usr/local/etc/smb4.conf
  • Output of getfacl /mnt/Volume.1/media
  • Output of smbstatus with active session from Windows 10 client.
 

Craash

Cadet
Joined
Jul 24, 2017
Messages
5
EDIT: This IS a band aid. Read on for enlightenment from @anodos including the preferred fix.

Perhaps this is a band aid, but adding the following took care of the issue.

Services, SMBand, Auxiliary Parameters text field:
ea support = no
store dos attributes = no
 
Last edited:

Craash

Cadet
Joined
Jul 24, 2017
Messages
5
Post following enclosed in [ code ] tags:
  • Contents of /usr/local/etc/smb4.conf
  • Output of getfacl /mnt/Volume.1/media
  • Output of smbstatus with active session from Windows 10 client.

In the interest of completeness, should I still post these items, or does the tweak I applied make sense?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Hmm... that makes it sound like you've somehow flagged files in your share with the "hidden" file attribute. These are stored in the user.DOSATTRIB (or something like that) extended attribute when "store dos attributes = yes" is set. There are three ways to disable it:

1) use a Windows client to turn it off for the file / directory
2) disable "store dos attributes"
3) use the following winacl command: winacl -a reset -x -r -p /mnt/Volume.1/media. Note that this command will reset permissions on your share to its default state and nuke the DOSATTRIB EA.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
In the interest of completeness, should I still post these items, or does the tweak I applied make sense?
The problem with your tweak is that "ea support = yes" is required in the current version of Samba for the "fruit" VFS object to work properly. If you have mac clients, you want to use fruit.

"store dos attributes = no" works independently of "ea support = yes". You should be able to safely enable the following auxiliary parameters under Services -> SMB

Code:
store dos attributes = no
map archive = no
map hidden = no
map system = no
map readonly = no
 

Craash

Cadet
Joined
Jul 24, 2017
Messages
5
I tried using a win10 client to remove any H attribute (after turning dos attributes back on).
From an elevated command prompt: attrib -H m:\* /S /d - no love.

BUT, the winacl command ran from the shell of the freenas machine took care of it.
winacl -a reset -x -r -p /mnt/Volume.1/media

I've reset my perms and all is well.

What benefit does the "store dos attributes" bring? My primary concern on this NAS is performance (SMB/NFS). Would I streamline it any if I disabled it?

Thank you so much for the great help!


Hmm... that makes it sound like you've somehow flagged files in your share with the "hidden" file attribute. These are stored in the user.DOSATTRIB (or something like that) extended attribute when "store dos attributes = yes" is set. There are three ways to disable it:

1) use a Windows client to turn it off for the file / directory
2) disable "store dos attributes"
3) use the following winacl command: winacl -a reset -x -r -p /mnt/Volume.1/media. Note that this command will reset permissions on your share to its default state and nuke the DOSATTRIB EA.
 
Status
Not open for further replies.
Top