One of my personal shares has stopped allowing saves or creation of folders. It gives the following message when trying to create a folder anywhere on the share:

I can Create a new Share with a different name and move all files over physically & things work just fine.

I can RENAME the original Share and things work just fine.

But if I rename a new Share to be the same "old" name, I again get the listed error. I feel it is a corruption linked to the original Share and some unresolved issue, but I am not versed enough in Linux to figure out what to do.

I'd like to get back to my old name of the Share due to links to it on other machines.

Any help is appreciated.

1--- Post up the Diagnostics file in a new post in this thread.

2--- Give us the full name of the share with the problem.

"Chris" is the name of the Share.

tower-diagnostics-20260403-1609.zip

Try going here:

Set that #3 value to a reasonable value based on the largest file you will be transferring to that share.

Ok, it was set to 42 GB, and I lowered it to 20 GB. Same result.

I then raised it to 50 GB and again same result.

Edited April 3Apr 3 by ClawSS

If I rename the share and keep all settings the same, I am able to write to the share.

If I change the share to write directly to the array, then I am also able to write to the share.

9 hours ago, ClawSS said:

If I rename the share and keep all settings the same, I am able to write to the share.

If I change the share to write directly to the array, then I am also able to write to the share.

I would be having a good look at the cache drive.

Let me ping @JorgeB and see if he might have some thoughts.

EDIT: One more thing. What is sending this file to Unraid? (I don't recognize the format of that error message...)

Edited April 4Apr 4 by Frank1940

Apr 3 15:54:12 Tower smbd[3168239]: [2026/04/03 15:54:12.351061, 0] ../../source3/smbd/smb2_service.c:117(chdir_current_service)

Apr 3 15:54:12 Tower smbd[3168239]: chdir_current_service: vfs_ChDir(/mnt/user/Chris_Share) failed: No such file or directory. Current token: uid=1009, gid=100, 2 groups: 100 10000

Is Chris_Share the name you renamed it to? Appears to be trying to write to a share that doesn't exist.

Yes Chris_Share was a rename. The error is from Windows when the share was Chris and I was attempting to create a new folder in file explorer.

Do I need to add a new diag. file? I have put the share names back to where they were prior to my testing.

Try Tools - New Permissions on the share in case something like that is the real problem.

6 minutes ago, ClawSS said:

Do I need to add a new diag. file?

Yes.

Make sure that it covers a time period when you had the problems. You might actually run a test where you have failure and note the time and date for quick reference. give test details...

I tried the New Permissions earlier, but will again just on that Share.

I attempted to write again this morning and captured a new diag. file here.

tower-diagnostics-20260404-0815.zip

OK---- I just did a test. I created a share called Test and set it up for private access. I copied one file to it.

I then renamed it Test_Rename

From Windows File Explorer, it remained Test Windows refused to recognize that Test had been renamed. I evened started-and-stopped the array. Windows still did not recognize the name change.

I finally restarted the Windows machine and it now recognized the Test_Rename share. I copied a second file to it. That worked.

Quick and dirty conclusion. Renaming an Unraid share is not a a simple trivial task if Windows is involved! You will probably have to restart both the server and any Windows clients involved.

That’s the thing…I’m not wanting to change the share name. It just now decided to not let me create into it giving the initial error. Rename activity is only a test mechanism.

What do you get from command line with this?

ls -lah /mnt/user

and this

ls -lah /mnt/user/<sharename>

4 minutes ago, ClawSS said:

That’s the thing…I’m not wanting to change the share name. It just now decided to not let me create into it giving the initial error. Rename activity is only a test mechanism.

Then don't use it as a test mechanism... 🤪

Let's do all testing on a single share. And remember that rebooting/restarting the Windows clients may be required to totally refresh SMB after changes are made to SMB configurations.

I renamed and found that I could do what I needed. I changed it back and again couldn’t. I thought that was a clue when just by renaming the top level folder allowed the cache to work without any other changes to the setup of the share.

Edited April 4Apr 4 by ClawSS

Are you renaming the share using the GUI? Also, if you create a new share and set it use cache first, can you copy the same file(s) that are giving the error?

I am renaming using the GUI. There are no files giving me errors. I cannot create a file or move one to the Share. All of the files I have looked at on the share will open in windows fine. I just cannot update and resave them to that Share.

If I create a new Share and physically move existing files to it, I can access and create files and folders fine.

I have no problem deleting the old share at that point. But if I rename the new share to the name of the old one or create a new share with the original name…I cannot write to the share any longer.

And if you still have a problem, be sure you do this

8 hours ago, trurl said:

What do you get from command line with this?

ls -lah /mnt/user

and this

ls -lah /mnt/user/<sharename>

and post it up.

What would that data tell you besides the names of the owners of the shares? Why share this on a forum?

If it was permission related, I doubt I could rename and it work and change back and fail. The permission would not change nor would it change back after an un-rename.

Right?

2 hours ago, ClawSS said:

All of the files I have looked at on the share will open in windows fine. I just cannot update and resave them to that Share.

Is this a Public share?

Private