It sounds like a default file permission is being set wrong somewhere.
But really, you left out a lot of information that might be helpful:
- What operating system is the desktop?
- What operating system is the server?
- What file sharing protocol is being used?
- What program is being used to save files? SAS for Windows? SAS Enterprise Guide, SAS Studio? An external editor?
- Does it affect only SAS program files, or other kinds of files as well?
- Does it affect all users, or only some?
%put &=SYSSCP; %put &=SYSSCPL;
and look at the log to determine the operating environment of your SAS server.
Oh, well. On a UNIX server, I would suggest to log on to the commandline via SSH and inspect the file's permissions with UNIX tools. You need to try similar, to get a view of the situation from your user's view when looking from the server side.
I don't about how Windows does file sharing. I know if hates it when someone has the file open. Make sure there are not processes that are keeping the files open. Are you trying to modify a program that is currently being run by some batch job? Is there some archive process that is locking the files?
On Unix you might see something like that with improper UMASK settings. If the users are in different groups and the group write bit is NOT set on the file, but is set on the folder then you will be able to make new files and delete existing files, but not be able to directly modify a file. Have your IT check if the network drive is being managed by Unix and not Windows.
Indeed, as @SASKiwi requested, if you could please mark your own post as solution, it would be great.
By the way, you should be able to find some evidences in the Windows Event Logs. My 2 cents to your story @cgates .
Just for the record and others coming to this post looking for solution, I will share an experience I had recently. It was on Linux, not Windows, but I think that for all matters, is similar. It could be a possible solution for some situations, specially for those when "nobody did anything to resolve it, and still it is resolved".
When you generate a sas file, being a sas dataset or a sas code/file, you will do it in a certain set of locale and encoding, based on the ones defined in your OS session, but also in the SAS session used to generate the file.
When another SAS session that had a different set of locale and encoding accessed a file generated with their own session, they could access it, and they could save over it. But for files created in different locale/encoding, it could happen one of these 2 options:
- the dataset of file is not even showing up (if the name contains chars from a different charset than the reading session)
- the dataset of file shows up, but cannot be overwritten (if the content is in an unsupported encoding to your session).
The story of this posts makes me think that, perhaps different SAS Foundations - perhaps even from the same machine, as SAS foundation offers different start ups through NLS (National Language Support) configurations - with different sets of locale/encoding generated the issue - but also could resolve the issue on itself once the usage of SAS foundation gets into standards and everyone uses what they should use, with the configuration that is expected.
Bottom-line and long-story short, specially for collaborative environments where people from different countries work together: always mind the locale and encoding of the session, and the outputs.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.