cmet

I went back, and set up the remotes through the unraid UI and went back to rsync to validate the migrations, etc. and everything seems to be alright now. So either something related to manually mounting source dirs in the /mnt directory, which doesn't entirely make sense to me unless it indirectly impacts the other serving up of the shares. Or there was some sort of caching issue on either the server or windows client given I was transferring thousands of subdirs in some of these shares at once. Or something else entirely.

Ok I'll try changing the remote mount around, thanks guys. I'm also noticing some of the copied folders are not visible on windows again after using pure `cp` overnight. Will need another day to resolve everything and try some more tests.

root@unraid:~# ls -al /mnt total 16 drwxr-xr-x 13 root root 260 Dec 25 22:54 ./ drwxr-xr-x 20 root root 420 Dec 27 13:56 ../ drwxrwxrwt 2 nobody users 40 Dec 25 22:36 addons/ drwxrwxrwx 1 nobody users 40 Dec 25 22:05 cache/ drwxrwxrwx 6 nobody users 77 Dec 27 15:09 disk1/ drwxrwxrwx 2 nobody users 6 Dec 25 22:05 disk2/ drwxrwxrwx 2 nobody users 6 Dec 25 22:05 disk3/ drwxrwxrwt 2 nobody users 40 Dec 25 22:36 disks/ drwxrwxrwt 2 nobody users 40 Dec 25 22:36 remotes/ drwxrwxrwt 2 nobody users 40 Dec 25 22:36 rootshare/ drwxr-xr-x 3 root root 60 Dec 25 22:56 tower/ drwxrwxrwx 1 nobody users 77 Dec 27 15:09 user/ drwxrwxrwx 1 nobody users 77 Dec 27 15:09 user0/ I've recreated all of the shares and things seem to be working as expected at the moment. Recopying using `cp` instead of `rsync -avzP /mnt/user/share/ /mnt/tower/share` (tower is the older unraid server, with its shared dir mounted at /mnt/tower as seen above. Everything else should be stock unraid.)

+1 in 2023, seeing this same behavior on a fresh unraid 6.12.6 install. I'm not yet able to narrow down where the source of the behavior lies.

Hm, not seeing anything else odd with anything, they all have the same permissions assigned from Tools > New Permissions. Another odd behavior, if I open the share dir from Windows, and create a New Folder- I can never see it. It seems as if nothing has happened. But then going on the unraid terminal, I can see the files there which have been created drwxrwxrwx 1 nobody users 10 Dec 27 14:26 New\ folder/ drwxrwxrwx 1 nobody users 10 Dec 27 14:33 New\ folder\ (2)/ drwxrwxrwx 1 nobody users 10 Dec 27 14:33 New\ folder\ (3)/ I'm not very trustful of new Shares being created with the newer version of Unraid. It feels like it's something to do with how the shares are being created/served rather than the files within them. Maybe someone else will find this thread on a google search in the future. I am also seeing this exact issue from 2020 that does not look to have been resolved. I can copy to subdirectories but not directly into the share directory. Signs are pointing to a Windows issue, even though I'm seeing this on two different machines on my network. Oh well the troubleshooting continues.

If anyone has any ideas for what else I can check for differences between these directories it would be appreciated. All permissions etc appear to be the same. I'm not sure if there is something special with Unraid OS going on if I copy directly into the /mnt/user/<share>/ directory or if perhaps I should be doing a migration copy somewhere else preferred?

I'm at my wit's end with this. Brand new unraid install 6.12.6 1. Run Tools > New Permissions on <share1> 2. Create a new Share for <share2>. Primary=Array, no Secondary. SMB Export=Yes, Security=Private. Added Read/Write access for my user. 3. From terminal, copy all subdirectories from share1 to share2 cp -r /mnt/user/share1/* /mnt/user/share2/ All files and dir are assigned to root:root after this copy, so run Tools > New Permission on <share2> 4. From Windows machine, navigate to \\unraid\share2, authenticate, and only some of the subdirectories are visible. Try to directly navigate to "hidden" subdirs and Windows reports unavailable. Try from different Windows machine and same behavior is observed. Both Windows machines have file explorer configured to see hidden and system files, etc. Two example dirs, one that can be seen over the SMB share and one that cannot appear to have all the same settings root@unraid:/mnt/user# ls -ld share2/X.\(2006\) drwxrwxrwx 1 nobody users 123 Dec 27 13:35 share2s/X/ root@unraid:/mnt/user# ls -ld share2/Y.\(1994\) drwxrwxrwx 1 nobody users 108 Dec 27 13:36 share2/Y/ same for file contents, etc. I'm not sure what else to check, this seems very bizarre to me. All files and directories involved use alphanumeric character plus parentheses and periods only. All subdirectories and files are visible from terminal, just not via SMB on Windows. Previous server unraid 6.9.2 doesn't appear to have any issues with the same directories. If I copy over files from the older unraid server to the new one via Windows rather than rsync on the destination server directly, I don't see to have this issue (but that's much much slower, etc.) Diagnostics does not appear to contain anything interesting, no errors. syslog.txt looks good etc. I'd prefer not to share it on a public forum since it does contain a decent amount of personal info even when "anonymized".

To clarify, all subdirectories and files in the share are assigned to nobody:users via the New Permissions tool, but the only way that makes anything visible is if cp ./dir to ./dir2 and then only dir2 is visible to my windows machines a day later and this is no longer the case. Copies remain inaccessible over SMB

I've run New Permissions many times, it sets nobody:users etc, but that has no impact on this issue as noted earlier by the other user.

I am having the same issues after using rsync with the archive flag, copying to /mnt/user/<share> directories. I did notice that if I copy one of the subdirectories which are invisible to my remote windows machine to a new dir, it is immediately visible to everything including the Windows machine, while of course owned by root:root which made the copy. If I re-assign ownership to nobody:users I can STILL see the subdirectory from remote Windows. But nothing I do makes the rsync'd directories visible to the remote windows machine over the share. I'm at a total loss to explain what's going on here. I have the same overall experience as all the descriptions above, files copied via the Windows machine over the share work fine, it's only issues with rsynced files on the unraid server itself directly as part of a server migration. (edit: copying directories does not appear to work anymore on this unraid server after migrating all files and continuing to troubleshoot, no idea what is going on) The S, T flag issues mentioned in the last comment aren't a factor for me over here though.