04-23-2015 04:38 PM
We have SAS installed on a server and we use enterprise guide to connect to SAS. In the past 2 years, we had several occurrences where all the files in SASapp are suddenly deleted. It is a random event and we haven't been able to figure out why these files sometimes disappear. Our temporary solution is to have a a copy of the SASapp folder and when it disappears we just paste the files from the backup. However, we would like to understand how this thing happen.
There is no real time effect. It happened 2 times last weeks on different day and times. it also happened 6 months ago and several times before. Multiple users are using EG to connect to the SAS server and they don't have the right to modify the files in SASapp. Our workspaces are on a dedicated drive.
We also noticed that sometimes files and folders are written in SASapp. It is very strange and we haven't been able to identify any reasons or any way to troubleshoot it.
Do you have any clues of what is going on on our server?
04-24-2015 04:17 AM
Check which users have write permission on the affected directories.
Also check if there are access control lists in place.
It can also happen that the files are not deleted, but a whole subtree is inadvertently moved. This only requires write access to the directories containing the root of such a subtree.
Try to narrow down the time window when it happened, and check which userid was logged in at that time.
Check the crontab (if UNIX) of the superuser or other userids having write access.
Check if a faulty maintenance script that is run to fix anything may unintentionally have run amok.
eg I once issued this command (as root):
chgrp -R newgroup .*
to change the group on all files starting with a dot (like .profile, .sh_history) in a user's home directory.
(the user had switched to another primary group)
Too late I realized that .* also includes .. (pointing to /home!)
Took me a day to fix that.
04-24-2015 04:20 AM
If mysterious files appear:
- do they look like files usually used in the SASApp tree (.sh, .log, .cfg, .sas7bdat, ...) or completely unrelated?
- look at the creation/modification date and correlate that with the logins/crontabs
Sometimes the modification timestamp on the directory will reveal when a file was last moved there (because that doesn't necessarily change the file itself) or deleted from there.
04-27-2015 02:35 PM
Having the sasapp folder being getting disappeared is a bad installation configuration. That directory is one toe be administered by a high privileged account.
Either you are running something with that that is corrupt or badly designed (remove all files older than ...). Or you are running your daily processed by that may be some easy mouse move causing that.
You may have heard of do not processed under root (Linux) , do not run your processes by the local/domain admin (windows). Why are you/we doing that with the holy sassrv and sasadm account with SAS?
04-27-2015 02:51 PM
Thank you for your answers. I am just one of the SAS users in my company. The server and SAS were installed by the IT department and we are using a window virtual machine I believe.
Users don't have the right to write to this folder and that's why it does not make sense to us. It is very strange because last month for example, we noticed that one program created 3 folders in SASapp directory. This program has been working fine for a couple of months. It actually writes to a sharedrive and there is nothing about the C:\ on the server in the SAS code it is an automatic program schedule by a windows task. My assumption is that at some point we lost the connection to the sharedrive for whatever reason. Since the SAS program did not find the shared drive, it wrote directly to SASapp.
It could also explain why the files are deleted in SASapp. If SAS use this fodler SASapp as a workspace (for an unclear reason), it would delete everything when it clears up the workspace. I just cannot find a way to replicate this situation. It just happens randomly and so far no one has a clear answer.
04-27-2015 03:24 PM
Your added description is a fit for a Unix known issue. I assume the same is valid in a Windows environment. 50345 - Changing the current working directory for the SAS® Workspace Server
For some weird reason SAS assumed the current directory to be that location. That is the SASapp one where you are experiencing your problems.
It is forcing you to hard code full path names as much as possible. That is not a very reliable approach as when at some moment to current dir is open and accessed it will happen.
You think that will not happen as you have carefully coded it with full pathnames... SAS(R) 9.4 Companion for Windows, Third Edition (this is the DMS approach not valid with Eguide SASapp).
Getting programs designed and tested with that could be violating your assumption. When trying to replicate use Eguide and all SAS functions not the RDP and Windows-explorer.
The reason of shutting down xcmd access is that be default SAS is running very high privileged access (local-system account) for all sas-processes they must restrict that with according lowering privileges when that fails all is local-system privilege. NOT the excpected user-level privilege. This is easy to check when you have xcmd access, when you do not get that assume it is open.
Ahh,there is another SAS autocorrect feature. When there is failure on the existence in the full path a switch can be mode to try that in the current dir. (seen this happening)