I woke up this morning and all of my linux VMs and windows machines have lost their SMB connections to my Scale server. These VMs and windows machines are not on the Scale box. I have rebooted the Scale server and the VMs and they are all getting Permission Denied still. I have made no changes. This suddenly happened in the middle of the night. I upgraded to Electric Eel a couple weeks ago (currently on 24.10.0.2) and have been fine so far. I have double checked the user/password is correct. I have tried creating a new SMB share and that doesn’t work either. I have checked that my user has full permissions.
This is in the smb log:
[2024/11/18 08:54:00.040947, 0] …/…/source3/smbd/smb2_service.c:117(chdir_current_service)
chdir_current_service: vfs_ChDir(/mnt/Pool1/Apps) failed: Permission denied. Current token: uid=1000, gid=1000, 6 groups: 545 1000 90000005 90000012 90000017 90000002
failure to chdir means that you broke permissions on either /mnt/Pool1 or /mnt/Pool1/Apps to prevent chdir for that user (uid 1000). E.g. you removed execute permissions from dir.
That’s just it… it happend in the middle of the night. I just checked and my backup Scale box is doing the same thing. These are on my home network and the backup box was isolated on a completely different network. All the premissions, UID/GID, that I can see are still the same they were before. Are there any other logs that I can check?
It looks like you performed chmod 700 of /mnt/Pool1. We don’t expose this in the UI and backend APIs explicitly prevent this from happening. chmod 755 /mnt/Pool1 will fix it.
That’s a possibility. Depending on how the path is being used an app may think it’s supposed to exclusively own a given path (like your entire pool) and break access for everything else.
Auditing is much more extensive in 24.10. You can look at audit trails in UI for middleware and see what configuration changes were made during the specified time period.
