Can't rename a folder that was duplicated (copy of the original folder)

[eduardooliveira]

Hi,


We just started to use Truenas Scale coming from previous experience with Truenas Core. This is a brand-new install, not a migration from one system (Core) to the other (Scale).

So, accessing folders from a Windows machine is fine and all permissions are set properly (no one has issues creating files, folders etc) except for one thing...

When making a copy of any existing folder and trying to rename it will say that the folder is already open on another machine or opened by another person when it is not! If we wait a couple of minutes (5 -10 min or so) it will allow us to rename the folder with no problems. Oh, we can rename the original folder with no problems, only the new folder copy cannot be renamed....
That said, this is not a permissions issue but something that is getting stuck right after the copy of the folder is created and preventing it to be renamed.

These folders came from a Windows 10 computer that was acting as a file server before where this issue was NOT happening. It only started after we deployed the Truenas Scale. I have implemented Truenas Core in the same scenario (moving from a Windows Machine action as a file server to Truenas) and that was not a problem at all...

There is nothing unique about the folders really. only a few subfolders, some empty and some with word/excel/PDF files.

Also, we can delete the new folder copy but some subfolders may say that they are open and/or cannot be deleted (even some there were already empty when copied from the template folder). I also investigated hidden contents and there is nothing inside these folders. Again, trying a few minutes later that works ok OR if you do it from another computer (same user or different user, does not matter)

So, the interesting fact is... if I try to rename or delete that new folder that was just duplicated but now from a DIFFERENT machine without waiting (all Windows 10 running the same build) that will work just fine. But not from the machine that created the copy.

Any ideas?
I do not think that this is an issue with the server-side copies failing on the machines since 1) it still works on any other shares, not on the Truenas, 2) I can still rename or delete from another computer the second the copy of the folder is created 3) affects all computers in the network when they create a copy of the folders, 4) there are only 6-7 computers on the network at the same time at maximum (normally 5) and they are not all the time accessing files on the Truenas Shares (or even the same folders at the same time)

 

[sretalla]

SMB allows Windows to initiate a server-side operation from the client, so a copy may still be in progress even if your client thinks it's done.

Even if that's the case, that doesn't explain the whole story, so I'll throw a second idea in there to make it complete...

After the client asks for the change, it isn't updating its own copy of the metadata about the copied items, so until it gets an update from the server, doesn't see the files in the new location yet or is somehow in the middle of getting updates.

I don't know the process that triggers that update, but I guess it could be periodic... maybe you can force it with a refresh or something?

I guess that relies on the errors reported being somewhat generic and not the actual root cause of the inability to work with the new files.

 

[eduardooliveira]

SMB allows Windows to initiate a server-side operation from the client, so a copy may still be in progress even if your client thinks it's done.

Even if that's the case, that doesn't explain the whole story, so I'll throw a second idea in there to make it complete...

After the client asks for the change, it isn't updating its own copy of the metadata about the copied items, so until it gets an update from the server, doesn't see the files in the new location yet or is somehow in the middle of getting updates.

I don't know the process that triggers that update, but I guess it could be periodic... maybe you can force it with a refresh or something?

I guess that relies on the errors reported being somewhat generic and not the actual root cause of the inability to work with the new files.

Sorry, but I still can't see this as a server-client issue,

There is no way a folder that is 2KB containing 4 files on a 1GB network can take 5-10 min to finish the copy (tested with many different folder sizes and etc and does not matter if the folder is just this small, the same process will be presented). Furthermore, this same folder CAN be renamed and manipulated from another machine right away while it cannot from the machine that initiated the command to create a copy.

It could be an issue with the client not getting the update metadata... maybe, but it is still odd that another computer can see the "- Copy" folder and can still manipulate it / rename it.

For example:

Machine A and User A access path Z:\TruenasShare\ and create a copy of folder "YZX" on the same path creating the "YZX - Copy"
Machine A and User A can't rename the folder "YZX - Copy" but can still delete it or access its content. When trying to rename shoes a message that the folder cannot be renamed because it is open on another location or there are files open on that folder (which is NOT true since I have also isolated this by creating another dataset and Share for testing and had no other computer accessing that test share)

Machine B still with user A (or any other user actually that also has permissions on that path) can see all the folders including the "YZX - Copy" and CAN RENAME IT.
Right after the folder is renamed by the Machine B the Machine A can rename it again or do anything.

This will also be the same if we initiate the process from Machine B instead of A.

That means that the data is there, the copy was completed, and the machines can see it but for some reason, it gets locked and cannot be renamed by the one who created that "YZX - Copy" folder. I will allow it to be renamed only after 5-10 min and refreshing the folder or closing explorer and opening again also does not work as a workaround. Folder update should be almost instantaneous and we never had issues with the same scenario with Truenas Core but we do see issues with SMB and printers (for example, printers not being able to access the share again after the first scan is sent to a scan folder which in this case was confirmed as a bug and a patch to be included on the next release but this is different from the issue of renaming the folder described above even though is SMB related..)

 

[chrisaddison]

I have the same issue. TrueNAS-SCALE-22.12.0. This is very frustrating and I'd love to find a solution.

 

[eduardooliveira]

I have the same issue. TrueNAS-SCALE-22.12.0. This is very frustrating and I'd love to find a solution.

Sorry to hear that but at least I am not alone...

I am about to remove the TrueNas Scale and install TrueNas Core since I never had problems with it.

 

[groats]

[TrueNAS-SCALE-Bluefin 22.12.1 / Win11 Pro all updates including the CopyBug patch]

I've been having similar issues since upgrading my box from Anglefish to Bluefin.
The problem still exists for me after the current Bluefish update.
I tried everything. I have also created an Admin UI user, as described in the DOCS, I have already created all my shares and datasets and written new ACLs.
I have migrated my system from Freenas to TrueNAS Core and from there to Scale over the last 2 years. I haven't had any problems with Anglefish yet.
It's only since I switched to Bluefin Release that I've had problems like this.
You can see that no file is open from the Windows client via "smbstatus" in the shell.
However, if you use "lsof | grep '%FOLDERNAME'" to look for the folder that is supposedly still open somewhere else, you can see that it still seems to be open in the SMBD service etc. on the server side.
This also happens when I want to rename a folder in the same share/dataset, or have previously deleted something from it.
I have to kill the Task which is shown me via "lsof | grep ...." to rename or move the folder than, but that's very frustrated for me.

Is there already a workaround for this?

 

[eduardooliveira]

I guess the solution is to move back to TrueNas Core as I did and the issue is now "RESOLVED". Funny that some people (another other post I have created for the same issue) keeps blaming the Client Machine and SMB Server-Side when it was clear since the beginning that it was not the case.

There is also another issue with SMB on Truenas Scale that prevents you to use the scan to folder feature from printers which will allow you to scan once and will get stuck if you try again from ANY other printer as Truenas becomes irresponsible to the SMB requests, to ping, access, write or anything else originated from ANY printer ONLY so, be aware if you rely on this feature as well. It was supposed to be fixed on the last minor update but it was not fixed.

I will be waiting a couple more years before upgrading again to Scale.

 

[systract]

Did you enable ACL, while your file manager doesn't support ACL?

If that's the case, check it here:

Comparison of file managers - Wikipedia

en.wikipedia.org

 

[WyatTech]

I just joined to say I had the same issue. I restored to a previous boot environment and I am no longer experiencing the issue. I was on 22.12.1, and rolled back to 22.02.RELEASE.

 

[groats]

I guess the solution is to move back to TrueNas Core as I did and the issue is now "RESOLVED"

Thank you for your hint. I completely migrated my machine back to TrueNAS CORE (13.0-U4) yesterday. My pools and encrypted datasets were imported back without any problems. At the moment everything seems to be working fine again.
The problem is definitely the current scale version, or possibly the Samba version used there.

Did you enable ACL, while your file manager doesn't support ACL?

The ACL configuration doesn't seem to be the problem. In addition, Samba only sporadically choked on my latest SCALE version, which was very annoying.

I just joined to say I had the same issue. I restored to a previous boot environment and I am no longer experiencing the issue. I was on 22.12.1, and rolled back to 22.02.RELEASE.

^ Thanks, this is a very good tip for others who come across this thread.

In my case I have now (as written above) completely migrated back to TrueNAS Core.
Up to my jump to "BlueFin", Scale ran without any problems for me right from the start.

Since I don't need such a hassle again, i will stay with TrueNAS CORE for now!

 

[systract]

ACL wasn't problem, file manager was the problem in my experience.
It is fine after I switched from Total Commander to XYploer.
Not sure if it is the case for you tho.

ACL support list:

 

[eduardooliveira]

I just joined to say I had the same issue. I restored to a previous boot environment and I am no longer experiencing the issue. I was on 22.12.1, and rolled back to 22.02.RELEASE.

Great to know. In our case we got a brand new device from iX Systems so it came with Truenas Scale already installed. Anyway, not uprading to scale anytime soon for sure.