That’s not how you provide information. You post the whole line from the /etc/fstab because the information you omitted may give some hints.
Sorry for that, you are right. I have also shortened the real path above, I’ll avoid doing that because I may get confused when doing the replacements.
This is the full line in fstab that affects this mount:
//ServicesVM/Archive\0402\040-\040Old /mnt/network/smb/Archive2_Old cifs noauto,rw,user,resilienthandles,vers=3.1.1,credentials=/mnt/network/smb/credentials-ServicesVM,unix
And this is the full command user for mounting the share:
sudo mount -o X-mount.idmap=b:1005:1000:1 /mnt/network/smb/Archive2_Old/
Now onto the experiments.
What about access permissions? Can you access files restricted to the UID 1005 on this filesystem?
There is a text file on the share, with owner and owner group as 1005. Permissions are rwxrwx---. This is what I see when I am logged in to the server through SSH and run ls --numeric-uid-gid in the directory.
Locally, through the share, I see the same, but owner is root (0) (owner group is 1005 though), I assume it is bugged on server side. I’m fine with this for now, and this has been possibly fixed in recent versions (server runs the alpine linux release of Samba, which has a delay in releases).
cat-ing this file results in a “Permission denied” error. It succeeds if I do a chmod o+r on the file remotely, through SSH.
What happens when you create new file - which UID it gets (check on server)?
I am quite amused by what happens when I do this.
I said touch Archive2_Old/temp/testfile.
The system said Permission denied.
Then I said, ls -hal Archive2_Old/temp/.
And I see that the file is there. I see this new file through SSH too, stat confirms it was just recently created.
Regarding permissions of this new file, locally I see that its group owner is 1005, which is what is expected by the idmapping. User owner is root, but I assume that it is the same server-side bug as above.
Remotely this new file has user and group owner both as 1005, so it seems idmapping is indeed working to some extent.
Deletion with rm works without issue.
Writing with a piped echo fails with an error. After this, through SSH I see a new empty file.
Writing with vim also fails with an error (a strange one: “E166: Can’t open linked file for writing”), and through SSH I see a new empty file, and interestingly a vim .swp file with the contents I attempted to save.
Did you test with another filesystem types?
I did not, unless a bind mount counts. I tried to bind /mnt/network/smb/Archive2_Old to another path, and add the idmapping there. That resulted in a “filesystem was mounted, but failed to attach idmapping” error message.
I have a suspicion that part of the issues (user owner almost always reported as root, and I think thats all I found so far) are caused by feature instability in the Samba server, as the Unix Extensions is an experimental feature there. It is a version not too long after this was made into an experimental feature from a development-build-only feature.
But the more serious issues seem like things that happen locally. That is, displayed ID is original instead of mapped, permission error reported when creation was successful, cannot write data to files.
All but the first seem to be worked around by mounting the share with an additional noperm option, like this:
sudo mount -o X-mount.idmap=b:1005:1000:1,noperm /mnt/network/smb/Archive2_Old/
After this, touch works without an error, I can write files with piped echo and vim, and all changes are also seen remotely, when I check it through SSH.