SOLVED Seeking help from PhotoSync + TrueNAS users

[Constantin]

I have mostly made the transition to TrueNAS and SMB in general. As part of that process, I nuked my old pool and rebuilt it with a 3-way sVDEV, etc. That also meant redoing all the shares and that’s where I am currently failing.

I keep getting errors from PhotoSync as it cannot connect using the same exact credentials as before. I know the password login is good since I can browse the network volumes, yet, no transfer can take place. I tried using traditional permissions as well as the preferred ACL approach, yet I fail consistently.

so here is my plea: can anyone enjoying PhotoSync and TrueNAS happiness share how they set up their ACL permissions or traditional unix permissions? What does the command line show re: owners/groups? I’m not picky, I just want it to get to work again!

fwiw, I set my PhotoSync user to be the owner and the PhotoSyncuser group to be the group owner. Full permissions for both, recursive file permissions applied to directories and contents alike, etc. Yet I get SMB error bad network name which in the past was a permissions issue.

 

[Constantin]

Here is the error message that cat /var/log/samba4/log.smbd puts out when I fail to get to get PhotoSync configured. I can log into the NAS, select the share, etc. but then I get the above and the server collects the below. @anodos, is the pcap cache something I can fix?

[2021/04/14 11:01:24.380008, 1] ../../source3/printing/printer_list.c:234(printer_list_get_last_refresh)
Failed to fetch record!
[2021/04/14 11:01:24.380096, 1] ../../source3/smbd/server_reload.c:66(delete_and_reload_printers)
pcap cache not loaded

 

[anodos]

Here is the error message that cat /var/log/samba4/log.smbd puts out when I fail to get to get PhotoSync configured. I can log into the NAS, select the share, etc. but then I get the above and the server collects the below. @anodos, is the pcap cache something I can fix?

Those log messages don't mean anything in this context. You should be able to see authentication attempts if you run the command midclt call smb.status AUTH_LOG | jq.

 

[Constantin]

I see the attempts but I struggle to interpret them. Here is one of them:

{
"timestamp": "2021-04-14T12:10:27.471977-0400",
"type": "Authentication",
"Authentication": {
"version": {
"major": 1,
"minor": 2
},
"eventId": 4624,
"logonId": "0",
"logonType": 3,
"status": "NT_STATUS_OK",
"localAddress": "ipv4:192.168.1.221:445",
"remoteAddress": "ipv4:192.168.1.186:60653",
"serviceDescription": "SMB2",
"authDescription": null,
"clientDomain": "",
"clientAccount": "PhotoCvW",
"workstation": "",
"becameAccount": "PhotoCvW",
"becameDomain": "MEGACITYONE",
"becameSid": "S-1-5-21-1220970426-3998126643-4033739245-1008",
"mappedAccount": "PhotoCvW",
"mappedDomain": "",
"netlogonComputer": null,
"netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000",
"netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null,
"passwordType": "NTLMv2",
"duration": 8393
}
},

{
"timestamp": "2021-04-14T12:10:33.458357-0400",
"type": "Authentication",
"Authentication": {
"version": {
"major": 1,
"minor": 2
},
"eventId": 4624,
"logonId": "0",
"logonType": 3,
"status": "NT_STATUS_OK",
"localAddress": "ipv4:192.168.1.221:445",
"remoteAddress": "ipv4:192.168.1.186:60654",
"serviceDescription": "SMB2",
"authDescription": null,
"clientDomain": "",
"clientAccount": "PhotoCvW",
"workstation": "",
"becameAccount": "PhotoCvW",
"becameDomain": "MEGACITYONE"
"becameSid": "S-1-5-21-1220970426-3998126643-4033739245-1008",
"mappedAccount": "PhotoCvW",
"mappedDomain": "",
"netlogonComputer": null,
"netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000",
"netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null,
"passwordType": "NTLMv2",
"duration": 9537
}
},

As best as I can tell, the client can log in successfully because I can browse among network shares in the iOS app. Presumably, I wouldn't be allowed to browse unless my login / password had been accepted by the server? Yet, I still end up with a BAD NAME ERROR or a 36 error when I try to upload images. I just reran the permissions today and noted one weird issue.

The parent directory is called PhotoSync and has two sub-directories that are also shareable - one is called PhotoSync_CvW, the other PhotoSA, one for each user. The subdirectories show a 771 permissions with the applicable user login as the owner of each as well as the PhotosyncUser group. Yet, when I drop down into PhotoSync_CvW, the directory listing ("..") shows a different account as the user owner . Just weird. I wonder if I need to destroy this dataset and start over.

 

[anodos]

I see the attempts but I struggle to interpret them. Here is one of them:



As best as I can tell, the client can log in successfully because I can browse among network shares in the iOS app. Presumably, I wouldn't be allowed to browse unless my login / password had been accepted by the server? Yet, I still end up with a BAD NAME ERROR or a 36 error when I try to upload images. I just reran the permissions today and noted one weird issue.

The parent directory is called PhotoSync and has two sub-directories that are also shareable - one is called PhotoSync_CvW, the other PhotoSA, one for each user. The subdirectories show a 771 permissions with the applicable user login as the owner of each as well as the PhotosyncUser group. Yet, when I drop down into PhotoSync_CvW, the directory listing ("..") shows a different account as the user owner . Just weird. I wonder if I need to destroy this dataset and start over.

Nothing that dramatic will be required. Try updating to U3 and see if that helps.

 

[Constantin]

I'm running U3 now and the latest error I get when trying to transfer is "36". I presume that is a permissions issue?

 

[anodos]

I'm running U3 now and the latest error I get when trying to transfer is "36". I presume that is a permissions issue?

Possibly. Check output of `testparm -s`. May sure your share exists. If it does, run command smbclient //127.0.0.1/<share_name> -U <photosync_user_name> to verify that you have basic access to that share. If you can access, run "ls" to verify that you can list directory.

BAD_NETWORK_NAME errors usually mean either (1) share doesn't exist or (2) path for share doesn't exist.

 

[Constantin]

Thank you, @anodos !

I could log in and the device from which the photos are supposed to be transferred presented itself in the directory as expected.

root@MegaCityOne:~ # smbclient //127.0.0.1/PhotoSync_CvW -U PhotoCvW
Enter HOME\PhotoCvW's password:
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Thu Apr 8 06:20:32 2021
.. D 0 Thu Apr 8 06:27:39 2021
Grumpie D 0 Wed Apr 7 21:12:27 2021

31654455357 blocks of size 1024. 31612323020 blocks available

I was also able to traverse down to /Grumpie/Recents without any issues, which is where the images are supposed to be dumped.

 

[anodos]

Thank you, @anodos !

I could log in and the device from which the photos are supposed to be transferred presented itself in the directory as expected.


I was also able to traverse down to /Grumpie/Recents without any issues, which is where the images are supposed to be dumped.

In webui, turn up SMB log level to FULL, try it again, then send me a debug (System->Advanced->Save Debug).

 

[Constantin]

Will do and thank you. FWIW, I turned the SMB logging to full, reran multiple login and transfer attempts with PhotoSync. Then I requested the debug file, which is on its way to you now.

 

[Constantin]

This issue is now solved. @anodos was incredibly helpful, walking me through multiple levels of diagnostics to figure out what is going on. He identified that the PhotoSync iOS app seems to be dropping the underscore from the network share name, even if the name was selected from a list of browsable shares in the PhotoSync App menu.

The developer was also very responsive but initially was not able to reproduce the problem on his Synology. However, once he used the same share name as I did (PhotoSync_CvW), he was able to reproduce the error on his end too. This was made possible by the great help of @anodos by turning the SMB error collection setting to full (Services -> SMB -> Log Levels) followed by him looking through the debug log files once I had fired up PhotoSync on my iPhone, tried to setup SMB twice (which resulted in the Bad_NAME_ERROR), and also attempted transfers twice (which would throw a SMB 36 error).

So thank you, @anodos!

I was able to resolve the name issue by simply removing the underscore from the share name I use for PhotoSync. Now it synchronizes happily.