[SMB msg.sock permissions keep changing and breaking Samba]

Thanks both for the hints, looks like I've found the culprit in some hacky SW TPM scripts I had been playing with to get Windows 11 VMs running some time ago. It wasn't actually the plugins themselves, but a sneaky line in a User Scripts set to run on array start, which included 'chmod 0755 -R /var/lib'!

 

Steps tried today:

- Disable docker and VMs, reboot and check permissions - OK on initial boot, permissions broken when array is started.
- Additionally delete NerdPack (didn't realise it was deprecated) - same result, permissions broken when array is started. 
- Additionally delete SWTPM hacks in /boot/extras as I'm not playing with Win 11 VM any more - same result, fine until array is started.
- Started wondering exactly what happens when the 'start' button is pressed, then remembered the User Scripts plugin has schedule options including array start.... checked my scripts and realised that the SW TPM script was doing nasty stuff.

 

Thanks for the nudge in the right direction, that'll teach me to keep hacks that are no longer needed (esp since latest release has TPM support built in...) on my 'production' box! 

[SMB msg.sock permissions keep changing and breaking Samba]

For months now my ability to access Unraid shares from Windows seems to break randomly with the dreaded 0x80070035 error. Recently while trying to get it working again, I tried to run smbstatus on the CLI, and received the message:

 

root@unraid:~# smbstatus
invalid permissions on directory '/var/lib/samba/private/msg.sock': has 0755 should be 0700
Unable to initialize messaging context!

 

I did chmod -R 0700 /var/lib/samba/private/msg.sock - immediately smbstatus worked again and my Windows clients were able to access every share without issue. No reboots or fiddling with 'net use' necessary - it immediately worked.

 

The system continued to work fine for a few days, until I rebooted following an OS upgrade to 6.11.1 and the same situation occurred with the permissions needing reset. 

 

I'm happy that I can restore access immediately by changing the permissions back, but I'd like to get to the bottom of why. I guess either something periodic, on boot, or on samba startup that causes this - but I've no idea what. I have seen one other post that hints that tdarr might have some influence, but I've never used or installed that.

 

Has anyone any ideas please? The issue spans multiple Unraid versions from pre-6.9 thro' 6.11.

 

Cheers (diagnostics attached)

unraid-diagnostics-20221007-2239.zip

[[Support] binhex - rTorrentVPN]

1 hour ago, veri745 said:

Did you figure this out out?  I am seeing the same issue suddenly, and I have not changed my config in months if not years

My symptoms were quite similar to yours. Working fine, no config changes, just stopped working one night. Never did find a fix and moved to binhex-qbittorrentvpn instead, which is working fine.

[[Support] binhex - rTorrentVPN]

2 hours ago, ReDew said:

Take a look at the log files in "\appdata\binhex-rtorrentvpn\rtorrent\logs". It should be more specific about the error in there.

 

Interesting - the log file hasn't been updated since the time I shut down the running container. The timestamp is consistent with the when I rebooted my Unraid host to install a new NV driver and the last entries are: 

 

1644174856 N worker_rtorrent: Shutting down thread.
1644174856 N rtorrent main: Shutting down thread.
1644174856 N rtorrent disk: Shutting down thread.

 

Assuming this might be a permissions issue, I have created a new system user, changed the PUID & PGID of the binhex-rtorrent container, and deleted perms.txt before starting the container again. The user:group on all files has changed successfully, but the startup failure cycle still persists.  

[[Support] binhex - rTorrentVPN]

On 1/4/2022 at 5:27 PM, ReDew said:

I'm not sure what's going wrong with the initialization, but it is not starting and keeps looping.

 

.....

 

2022-01-04 10:59:31,589 DEBG 'watchdog-script' stdout output:
[warn] Wait for rTorrent process to start aborted, too many retries
[warn] Failed to start rTorrent, skipping initialisation of ruTorrent Plugins...

 

I am currently having a very similar issue. The container works on first run after barebones install & basic VPN config, but any subsequent restart of the container or the Unraid host causes the startup loop that you posted. 

 

/mnt/user/Media is mapped to /data in the container, permissions look OK, I'm a bit stuck now and would appreciate any advice. Thanks.