Share Name incompatible with FAT32 naming

hmm, this issue has been there for ... forever 🙄

This one is complicated not only because FAT32 is case insensitive, but also NTFS and windows in general is case insensitive (though recently per-directory case sensitivity option was added to Windows/NTFS).

 

For example, if we have:

 

disk1/movies

disk2/Movies

disk3/movies

 

Even though both 'movies' and 'Movies' are configured in /etc/samba/smb-shares.conf, windows will only present one of them in explorer (appears to be the first one).

 

The way we want to solve this is to exclude from shares list subsequent top-level directories that differ only in case.  For example, the list of shares will only include 'movies' and consist of disk1 and disk3 files.  Only the 'movies' share will be exportable.  However the /mnt/user/Movies directory will still exist and be locally accessible.

 

A side effect of this approach is this: if someone deletes disk1/movies then the share list will show Movies now, consisting of files on disk2.  So user would think, "hey I deleted disk1/movies, now all my movies are gone and where the hell did these Movies come from?"

 

Another side-effect is that since only 'movies' will be exportable, 'Movies' cannot be simultaneously NFS-exported.

Sounds complicated and confusing.

 

Since we're still tied to FAT32 for config storage, all the important thing I wanted to have happen was that if a share had a forbidden character in the share name that some sort of algorithm takes place to prevent emhttp from spamming the syslog with errors (because the share name is still perfectly valid under linux) (Which your post does not address)

 

The movies vs Movies vs MOVIES and SMB exporting and the complication of NFS and your idea I think will confuse the hell out of everyone when it does happen.  Perhaps an entry in the diagnostics in the shares section stating when a naming collision happens would be in order.

 

Another side note is that there are also reserved SMB names that are also perfectly valid share names that cause problems.

 

EG: "Homes" as a share cannot be properly exported and should have a warning issued if creating the share via the UI.  

I don't think it's quite as bad as you think, since at the same time we will prevent someone from creating multiple share names that differ only in case via webGui.  The only way someone could get into the situation is if they manually created top-level dir names in disk shares.

 

We will generate a syslog entry if a naming collision occurs during array start.

 

Do you have a list of all SMB reserved share names?

3 minutes ago, limetech said:

Do you have a list of all SMB reserved share names?

Here's one for sure

https://forums.unraid.net/topic/72568-user-share-homes/

 

I'll try and research in the next few days.

 

But like I said, there are also characters valid in share names that are invalid in FAT32 that wind up having emhttp spam the logs.

 

Nov 14 00:57:10 Tower emhttpd: error: put_config_idx, 609: Invalid argument (22): fopen: /boot/config/shares/:.cfg

https://forums.unraid.net/topic/75534-cant-pull-from-depositry/?tab=comments#comment-696730

 

7 hours ago, limetech said:

I don't think it's quite as bad as you think, since at the same time we will prevent someone from creating multiple share names that differ only in case via webGui.  The only way someone could get into the situation is if they manually created top-level dir names in disk shares.

 

We will generate a syslog entry if a naming collision occurs during array start.

 

Do you have a list of all SMB reserved share names?

Users have accidentally created top-level folders simply by misconfiguring their dockers to use the wrong case so it isn't necessary for them to have disk shares to make this happen. I have seen this many times and it seems to be the main cause of a user complaining that the share doesn't have their files in it anymore since Windows is showing them the wrong share.

3 hours ago, trurl said:

Users have accidentally created top-level folders simply by misconfiguring their dockers to use the wrong case so it isn't necessary for them to have disk shares to make this happen. I have seen this many times and it seems to be the main cause of a user complaining that the share doesn't have their files in it anymore since Windows is showing them the wrong share.

If you are saying that execution of a docker container can result in top-level directories being created, I'd say this is a bug in execution of docker containers.  ie, when container is started, if any top-level (share) directory does not exist, the container should not be started.

For a more concrete example, they will have a user share named 'media'. For the Host side of a volume mapping they will put '/mnt/user/Media'. This results in a share named 'Media'.

 

I just tested this myself and it does indeed create a new user share identical except for case.

But, if you look at the settings for that newly created share, it has adopted the settings of the other share instead of having default settings which further illustrates the other issue.

1 hour ago, trurl said:

I just tested this myself and it does indeed create a new user share identical except for case.

This behaviour has existed forever also.

4 hours ago, trurl said:

For a more concrete example, they will have a user share named 'media'. For the Host side of a volume mapping they will put '/mnt/user/Media'. This results in a share named 'Media'.

 

I just tested this myself and it does indeed create a new user share identical except for case.

This is a design flaw which we need to address.