'Trust relationship for the domain has failed' usually affects one PC when you try to log in. rejoining should have ironed that out. Each PC and the server keep a secret computer account password between themselves. They change the password every couple of weeks. If a PC is turned off for an extended period, or if you clone a PC that has been joined to the domain, or if you have two PC's with the same name then this can cause the share problems you are having and also cause the trust relation ship to fail because the server can not agree the new password with the workstation.
Opening Excel XLS from a shared folder should behave in virtually the same way from a workstation or the server but you reall should get it working from the server;
1. Create a folder.
2. On the folder properties > Security tab, add all the domain users with read/write NTFS permissions.
3. Share it and give all the Users read-write share permissions.
4. Put the file in and away you go
Best to use the server because it has a static ip which makes it more reliable to share from. Also the server's Shadow Copies will not be destroyed when the end user runs CryptoLocker (new variants DO kill System Restore on workstations), giving you an immediate fix.
If you insist on using Win7 to share from then make sure the AV/firewall is not blocking clients. Give the workstation a reservation in DHCP. If the folder does not show up then unshare it and reshare it. Do not use a dollar at the end of the sharename as this will hide the share.
Make sure the Server service is running on the workstation and that you have the File and Print sharing ticked on the workstation's network card. Make sure the workstation and its network card is not turning off with power saving.
If the file keeps getting locked then turn off the preview pane in Windows Explorer on all clients as this will open the Excel file to show the preview. Also you might need to turn off Opportunistic Locking but I haven't really had to do this since the days of DOS databases and older Sage versions:
https://blogs.technet.microsoft.com...e-definitive-locked-file-post-updated-772014/