SMB: Cannot move files with Apple clients

[chapchap]

Hi!

I have the following problem:

Using Apple clients (macOS and iOS) I can:
- move files and folders to SMB shares
- rename files and folders
- delete files and folders

However, I can't seem to be able to move files within one share (and dataset) from one folder to another.
On macOS finder, I hear the distinct "moved file" sound, but nothing happens.
Many times the allegedly moved file(s) will now appear twice in their original location until I revisit the folder.

This happens with the macOS finder, moving from the commandline / on a terminal on macos and when moving within the Files App on a iOS device.

I don't have any non-Apple clients but moving within a third-party iOS-App ("Documents") works just fine!

I ran smbdiagnose just before I tried to move a file.
While there are entries in the tcpdump, smbd.log was empty.

I am on TrueNAS Scale Bluefin Beta:

OS Version:TrueNAS-SCALE-22.12-BETA.2
Model:AMD Ryzen 5 3600 6-Core Processor
Memory:31 GiB

macOS 12.6.1
iOS 16.1

 

[ronny.a]

Could be unrelated but how have you configured your ACLs? I've experimented a lot and I've found that setting "ACL Type: NFSv4" and "ACL mode: Passthrough" and then "ACL preset NFS4_OPEN" on the dataset permission gives me (the only user in my system) a transparent macos<-->smb experience. What does ls -lah in the terminal show on the same file (create one file with touch somefile.txt and copy it around for example)

1. on your macos harddrive (not on the smb share)
2. copied onto your smb share mounted in macos
3. if you ssh to the server and look in the dataset

I expect the file permissions to be the same everywhere. If not then that might explain why you can do certain things but not others. ACLs can be very fine-grained I think, but for me at least I want a simple system.

 

[chapchap]

My dataset settings are:

ACL Type: SMB/NFSv4
ACL Mode: Restricted


When I creade I file (username is the same, password is not):

On the harddrive:

Code:

❯ touch myfancyfile.tmp && exa -lahg myfancyfile.tmp && rm myfancyfile.tmp
Permissions Size User    Group Date Modified Name
.rw-r--r--     0 bastian staff  8 Nov 10:04   myfancyfile.tmp

On the share:

Code:

❯ touch myfancyfile.tmp && exa -lahg myfancyfile.tmp && rm myfancyfile.tmp
Permissions Size User    Group Date Modified Name
.rwx------     0 bastian staff  8 Nov 10:06   myfancyfile.tmp

Copied to the share:

Code:

❯ touch myfancyfile.tmp && cp -i myfancyfile.tmp /Volumes/Share/ && exa -lahg /Volumes/Share/myfancyfile.tmp
Permissions Size User    Group Date Modified Name
.rwx------     0 bastian staff  8 Nov 10:08   /Volumes/Share/myfancyfile.tmp

then via ssh:

Code:

% ls -lah myfancyfile.tmp
-rwxrwxr-x 1 bastian root 0 Nov  8 10:08 myfancyfile.tmp

These are my permissions:

changing ACL Mode to passthrough changes the permissions of the file created when viewed via SSH:

Code:

-rw-rw-r-- 1 bastian root    0 Nov  8 10:23  myfancyfile.tmp

But the problem persists.

 

[maglin]

I believe the issue is you using the root user. Not sure about the latest SMB protocol but NFSv4 requires un/pw and not UID as it was previous. Try adding a user with the correct permissions and use that for your auth credentials. This is a stab in the dark but a very easy one to try.

 

[jolness1]

I am dealing with a similar issue since moving to bluefin.
I can copy a file from one folder to another but if I try to move the file, it seems like it moves briefly, then it ends up making a duplicate (think this is a MacOS side issue) that disappears if I reload that screen (either by closing out the folder and reopening or closing finder entirely). The weird part is that it works otherwise but just not moving from one directory to another in the same dataset.

 

[Daisuke]

I am on TrueNAS Scale Bluefin Beta

Latest version is RC1, this thread should be in Bluefin sub-forum.

I believe the issue is you using the root user.

That, you cannot use root user. Create a local user and assign it recursively to the dataset permissions, then login with it in your Mac, everything will work properly. ACLs have no influence BTW, I don't have them set. Is all about userid and dataset permissions.

Edit: I'm running Angelfish. I thought the OP is for Angelfish, you opened the thread into wrong forum.

 

[simonj]

We have the exact same issue. Two servers. One on TruenNAS core 13.0-U3 the other one on core 13.0-U3-1
The problem only happens with one share on the server running 13.0-U3-1. Also Mac clients. Happens with all clients.
I checked all the settings and parameters and they seem to be exactly the same on both servers and for all the shares.

@chapchap, did you find a solution?

 

[anodos]

We have the exact same issue. Two servers. One on TruenNAS core 13.0-U3 the other one on core 13.0-U3-1
The problem only happens with one share on the server running 13.0-U3-1. Also Mac clients. Happens with all clients.
I checked all the settings and parameters and they seem to be exactly the same on both servers and for all the shares.

@chapchap, did you find a solution?

There was an issue in BlueFin RC where vfs_fruit changed default from the zero_file_id parameter being disabled to being enabled. The theory was that when being presented with a zero fileid, the MacOS client would generate its own internal IDs. In practice though, it resulted in failed renames and other glitches.

One other issue I've encountered recently with the MacOS SMB client is that it hard-codes unicode precomposed names in outgoing traffic. This causes renames, unlinks, and many other ops to fail if the file on the remote server contains a decomposed unicode character. There's nothing we can really do on our end to fix this. MacOS is just semi-broken for compatibility with non-Apple SMB servers in this regard.
C.F. https://ixsystems.atlassian.net/browse/DOCS-4389

 

[simonj]

Thank you @anodos.
I realize only now that we are in the SCALE Bluefin forum. I am on TrueNAS Core. Didn't want to open a new thread when exact same issue was described by another user.

One other issue I've encountered recently with the MacOS SMB client is that it hard-codes unicode precomposed names in outgoing traffic. This causes renames, unlinks, and many other ops to fail if the file on the remote server contains a decomposed unicode character. There's nothing we can really do on our end to fix this. MacOS is just semi-broken for compatibility with non-Apple SMB servers in this regard.
C.F. https://ixsystems.atlassian.net/browse/DOCS-4389

Strange thing is that it happens with any folder as described above on one particular share. Moving any file or folder to another folder does not work but create a duplicate of the file / folder in the original place. That duplicate cannot be accessed or deleted. Finder gives a weird message saying: Object "?" cannot be moved to the bin as it cannot be deleted

 

[anodos]

Thank you @anodos.
I realize only now that we are in the SCALE Bluefin forum. I am on TrueNAS Core. Didn't want to open a new thread when exact same issue was described by another user.


Strange thing is that it happens with any folder as described above on one particular share. Moving any file or folder to another folder does not work but create a duplicate of the file / folder in the original place. That duplicate cannot be accessed or deleted. Finder gives a weird message saying: Object "?" cannot be moved to the bin as it cannot be deleted

Rarely issues are exactly the same even if they appear superficially similar. That's the reason why it's often asked to create a new thread. You can PM me a debug and I'll take a peek at it to see if there's an obvious misconfiguration.

 

[anodos]

The debug showed that "fruit:zero_file_id" had been enabled via auxiliary parameter.