Can't open sub folder in share from windows 11 or anywhere else after rsyn'ing data

[Bushibot]

I have bunch of data I copied over from an old nas.

Whenever I try open on those folders I get weird windows pop up saying the location in unavailable. I can brows to it fine via the unraid UI with no problem and everything looks intact. Other, non imported files and folders seem fine.

Screen shot showing exact message attached.

"[Window Title]
Open Folder

[Content]
\\NAS-MASS\Datapool\tvshows\Buffy The Vampire Slayer is unavailable. If the location is on this PC, make sure the device or drive is connected or the disc is inserted, and then try again. If the location is on a network, make sure you’re connected to the network or Internet, and then try again. If the location still can’t be found, it might have been moved or deleted.

[OK]"

Edited September 6, 2023 by Bushibot
clarified title

[JonathanM]

Try running the new permissions tool on that specific share.

[Bushibot]

 

39 minutes ago, JonathanM said:

Try running the new permissions tool on that specific share.

That did not appear to fix it.

I did a simple rsync of 1 folder with 1 subfolder.

rsync -azh --progress /mnt/remotes/192.168.1.90_Public/sshkeys /mnt/user/datapool/

The top level folder is fine, the lower level folder throws the same exact error when I try to open it.

Source data is validated as good and is accessible.

Permissions look fine?

nobody drwxrwxrwx <FOLDER> 

 

[Bushibot]

Redid without compression -z. No change. Reran tool permissions just to be sure. No change

New Permissions

Processing: /mnt/user/datapool ... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/user/datapool ... chown -R nobody:users /mnt/user/datapool ... sync Completed, elapsed time: 00:00:00

[Bushibot]

28 minutes ago, Bushibot said:

Redid without compression -z. No change. Reran tool permissions just to be sure. No change

New Permissions

Processing: /mnt/user/datapool ... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/user/datapool ... chown -R nobody:users /mnt/user/datapool ... sync Completed, elapsed time: 00:00:00

If I copy manually using windows to middleman, everything works fine. Subfolder is accessible and so is the test file.

This seems to be some sort of issue copying the data from unraid, via rysnc or Dynamix File Manager. Both copy tests have the same error.

I'm copying from a WD PR2100 NAS (raid 0) to my unraid host.

Frustrating. This is a hard stop for migration.

Edited September 5, 2023 by Bushibot

[Bushibot]

FTP to FTP via winscp produces the same problem.

So far only thing that has worked is smb to smb copy with a windows system in the middle 🤮

[Bushibot]

This problem is nuts. I'm now having to hand move large chunks of data and baby sit it since unraid seems to be changing a bit somewhere making sub folders copied in accessible to external devices.

[itimpi]

8 hours ago, Bushibot said:

This problem is nuts. I'm now having to hand move large chunks of data and baby sit it since unraid seems to be changing a bit somewhere making sub folders copied in accessible to external devices.

 

As far as I know you are the only one experiencing this issue, although I do not see what could be causing it.

[Bushibot]

39 minutes ago, itimpi said:

 

As far as I know you are the only one experiencing this issue, although I do not see what could be causing it.

I don't know either but it even if it's something on the source data side (WD PR2100 raid0) that is funky, though I can't imagine what since the old nas works fine, then it's still in how unraid is handling the data since it only presents back out to other devices.

[dboonthego]

On 9/6/2023 at 3:57 PM, Bushibot said:

This problem is nuts.

 

Just for kicks, what happens if you try your rsync test again without the archive (-a) flag?

[Bushibot]

23 hours ago, dboonthego said:

 

Just for kicks, what happens if you try your rsync test again without the archive (-a) flag?

I'm going to test this, but I have moved so much stuff by hand I have to go back and setup a new broken one :p. I want to say my first rsync was just -r but I can't quite be sure.

[Bushibot]

So a little more on this. I thought it was only related to migrated data, but this is not the case. It's popping up all over with new folders now created through containers.

What I have found is it seems related ownership.

I can't access from windows/mac sub folders owned by nobody. I can access top level shares though and they are owned by nobody.

I can access folders owned by root or griffon from windows/mac. 

 Can't access windows/mac: drwsrwsrwt 1 nobody users 74 Sep 10 12:10 folder1/

Can access: drwsrwsrwt 1 griffon users 160 Sep  7 02:30 folder2/

Can access: drwxr-xr-x 1 root root 4096 Sep  8 23:43 folder 3/

 

I thought ok let me just change the ownership... but that didn't fix it either, folders taken by root still remain inaccessible right next to ones that are.

[Bushibot]

nas-mass-diagnostics-20230912-1540.zip

[Bushibot]

I reran new permission tool on the shares. I had tried this before with zero change (several times, including the disk) but today when I did it worked for whatever reason and now I can mount the folders.

Ambiguity in system behavior makes my skin itch, but I guess I'm good for now.

post run

pre run  drwsrwsrwt 1 nobody users

postrun -rw-rwSrwT 1 nobody users 4294939196 Feb 19  201

 

I'm not really clear on the difference between the two or what the cap S and T mean or which value is significant here. I assume it will come back but as long the tool actually works I guess I'll just file it as dumb work around.

If nothing else I guess it show it is some sort of underlying permission issue or ownership thing.

Edited September 14, 2023 by Bushibot

[cmet]

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.

Edited December 27, 2023 by cmet

[trurl]

Tools - New Permissions

[cmet]

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.

[cmet]

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

Edited December 27, 2023 by cmet

[cmet]

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".

Edited December 27, 2023 by cmet

[cmet]

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?

[Frank1940]

Have look at the Parent directory and any child directories involved.  (Sometimes, the problem is not with the permissions of the current directory but with the parent directory and perhaps with permissions on the child directories.) 

[cmet]

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.

 

Edited December 27, 2023 by cmet

[Frank1940]

Run this command in the GUI terminal:

ls -al /mnt

 

Capture a screenshot of the output.  (All of the directories present should be default directories that Unraid sets up for all installs.)

[cmet]

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.)

Edited December 28, 2023 by cmet

[JonathanM]

10 hours ago, cmet said:

tower is the older unraid server, with its shared dir mounted at /mnt/tower as seen above

Current best practice would be to mount it in the /mnt/remotes/ path, don't know if that will change anything, but Unraid is sensitive about unknown items directly in the /mnt path, due to much of the filesystem being created in RAM.