It has come to my attention that there are now additional restrictions on the allowed characters in the Share Name in version 7.2.3. (Apparently, these were added to accommodate restrictions imposed by the ZFS file system scheme.) This was first brought to light in this thread:

https://forums.unraid.net/topic/197271-unraid-723-share-names-cant-use-spaces-or-any-special-characters/

I have tested the add share feature and discovered a couple of facts. First, I try to simply add a share with an illegal character, I can not do it. See below:

But if I use a bit of slight of hand and create a share by adding a folder/directory at the root of a drive, I can add a share with an illegal character. See below:

I verified that I could do all the things required in the share settings that one would expect. I exported, made it Private, assigned user permissions, changed the storage method to make Array secondary store and the single Cache drive primary, etc. Then using the Share, I created folders/directories via SMB, copied files to it, deleted files, ect.

Everything worked! The only thing that did not work was to be able to generate the share itself if it had one of the currently defined illegal characters in it.

Here is what I am requesting:

Change the logic on the ADD Share to allow creating a share with an illegal character if a ZFS component is not involved. (Leave the cautionary note. Change the Help files to indicate exactly why the restrictions on the characters is required and fro what services.

REASONING FOR REQUEST: I have no intention at this point of ever using ZFS! (Reason explained in the referenced thread.) I would assume that there are a lot of Unraid users who are of the same mind. Why should we be punished for a restriction imposed by the ZFS system? (And, why, one may ask, have the ZFS developers allowed such a restriction on naming to even exist in the day and age. This takes me back to DOS3.11 and CPM days!)

Edited February 19Feb 19 by Frank1940
missing comma

One more thought— Is there a logic scan of the a share with an illegal character in the share name which the user is attempting to modify the share to use a ZFS pool to prevent such a change from being made? (From a support standpoint, it is a vital consideration!!!)

Edited February 20Feb 20 by Frank1940
added "the Share" into the phase "modify the share to use"

+1

Posted request in in new section of Forum for Feature Requests...

https://product.unraid.net/p/fix-logic-on-add-share-tab

Is this reality a problem ?

2 minutes ago, digitaldoctor said:

Is this reality a problem ?

You actuality have this post in the wrong thread!

This has been a problem for a long time. I don''t have any MS Accounts or logins at my choice but I understand that many of them contain '@" as the login is a email address.

I have seen it recommended that Unraid users not use that Windows login (Which I understand Windows will try in its sequence to gain access to a server..) for this reason but use a different name and password in a Windows Credential..

EDIT: I did test this and there is logic to black adding a user which does not meet these requirements. Please remember that even though you may be using this user to access the array or pool via SMB, you are actually adding a user at the Linux level— not via SMB. You can access your shares via NFS using the same login credentials. A lot of these requirements go back to the origins of UNIX when the input/output devices were Teletype machines and those developers were not trained typists so they minimized all typing to an absolute minimum! . (Think of how people text message today!!!!)

Edited February 23Feb 23 by Frank1940

12 minutes ago, Frank1940 said:

I don''t have any MS Accounts or logins at my choice but I understand that many of them contain '@" as the login is a email address.

I only have local accounts as well. But all my local client logins have capital letters.

Windows SAMBA share networking has really gotten weird in Windows 11. It often works, but when it doesn't it's weird.

5 minutes ago, digitaldoctor said:

I only have local accounts as well. But all my local client logins have capital letters.

Windows SAMBA share networking has really gotten weird in Windows 11. It often works, but when it doesn't it's weird.

39 minutes ago, Frank1940 said:

EDIT: I did test this and there is logic to black adding a user which does not meet these requirements. Please remember that even though you may be using this user to access the array or pool via SMB, you are actually adding a user at the Linux level— not via SMB. You can access your shares via NFS using the same login credentials. A lot of these requirements go back to the origins of UNIX when the input/output devices were Teletype machines and those developers were not trained typists so they minimized all typing to an absolute minimum! . (Think of how people text message today!!!!)

If you follow the rules for MS security it generally works without issue. See this thread for those and why:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/

You can not always have things work the way that you want them to. You should be setting things up so that they work the way that the people who have control of the system want you to use it. Screwing around with group policy editor or registry editor in an attempt to fix things to work the way you want can result in problems in the future.

I understand that Apple OS's have SMB issues but there again Apple has their own way of doing things and MS and Apple don't have a great track record of cooperating with each other./

Granted that the Unraid server may not always show up under the 'Network' in Windows File Explorer but there is a workaround for this. (And this is not strictly an Unraid problem. I also have the same issue with my Windows peer-to-peer client/server computers!)

+1 to this.

I came here today with the same problem. Setup my server on XFS formatted drives with an earlier v7 OS. Named lots of shares -something-. Now today come to add another share and can't name the folder as I want to.

Please only put the restriction on the OS if there are ZFS drives. Reducing everything to the lowest common denominator is backwards. This should only be an advisory.

@Frank1940 Thank you for giving us a way around this odd limitation. This meant I learned that Linux didn't really like talking to a folder on the command line as -folder- and needed mkdir -- -folder- to make it happen. But it is still legal.

It was frustrating enough for me moving from NTFS where any character is allowed. My shares used to start with a ! and swapping to dashes caused a few hiccups. So it seems really really massive step backwards to end up with ZFS shares that only allow 26 letters of the alphabet.

LOL - what? I was testing something. I can't even name a folder café or Motörhead ? ZFS is so so so backwards. 🤣 So many of my folders don't use pure ASCII, which helpfully rules out me ever thinking about ZFS until they get that fixed.

Edited February 26Feb 26 by Batter Pudding

8 hours ago, Batter Pudding said:

Thank you for giving us a way around this odd limitation. This meant I learned that Linux didn't really like talking to a folder on the command line as -folder- and needed mkdir -- -folder- to make it happen. But it is still legal.

What I did was share (export) a 'disk' out via SMB and set the permission on that Disk Share to R/W. I then used Windows File Explorer to create a fold at the root of the share. Now, I had a User Share on the Unraid side of the house. Opened up the Share Settings for that Share and made all of the required settings. (Of course, I then turned off the Disk Share since my use of it was finished.)

I agree. I don't care at all about ZFS and this naming restriction has totally thrown off my shares and now my pools since the same rules apply there.