Cannot Save Modifications to Existing SAS Files - Only For A Certain Shared Drive Location

[cgates]

Update: Issue resolved on its own. My IT team and SAS are baffled as they never found a true solution. Other SAS customers are experiencing a similar issue so hopefully they get to the bottom of it.

Hello,
 
I have been using SAS for years at my organization. Starting last week, an issue occurred that is affecting my ability to save modifications to existing SAS files using SAS 9.4. Several other staff are experiencing the same issue but our IT department is stumped.
 
We have no issue saving new files, just saving changes made to existing files. To make matters more complicated, this save issue is only occurring on one of our shared networks. We have tested saving changes to existing SAS files to our desktops and to our Google File Stream drives and we have no issue there. Only with this particular shared folder that everyone uses where 99% of our SAS files are saved. 
 
Most people have resulted to saving the SAS file as a completely new program, which works. Then they go back to File Explorer retire the old file and rename the new file to the old name to save their changes. IT says there were no changes or updates implemented last week that would cause this issue, but they've been working on this for a week now and have found no solution. Any thoughts?
 

 
 
EDIT:
- What operating system is the desktop? - Windows 10
- What operating system is the server? - Unsure.
- What file sharing protocol is being used? -Unsure
- What program is being used to save files?- SAS for Windows
- Does it affect only SAS program files, or other kinds of files as well? - SAS program files
- Does it affect all users, or only some? - All users

[JackHamilton]

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?

[cgates]

I tried to provide answers that I know to the original post. Sorry, I’m not in IT just trying to find an answer to help them since they have no idea what’s going on.

[SASKiwi]

SAS obeys OS folder and file permissions. Something must have changed on the network share permissions to cause this. Also check the properties of the problem SAS files to see if for some reason the read-only flag is set. 

[cgates]

Thanks! I know for sure the read only flag isn’t set. We figured the same thing about the network share permissions but IT cant find anything.

[cgates]

Thank you! The issue persists so we're working with SAS support now to try and resolve it. I'll post the error when it's identified.

[Kurt_Bremser]

Run

%put &=SYSSCP;
%put &=SYSSCPL;

and look at the log to determine the operating environment of your SAS server.

[cgates]

Thanks!

SYSSCP=WIN
SYSSCPL=X64_10PRO

[Kurt_Bremser]

---

@cgates wrote:
Thanks!

SYSSCP=WIN
SYSSCPL=X64_10PRO

---

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. 

[cgates]

Thank you! The issue persists so we're working with SAS support now to try and resolve it. I'll post the error when it's identified.

[Tom]

---

@cgates wrote:
Thanks!

SYSSCP=WIN
SYSSCPL=X64_10PRO

---

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.

[cgates]

Update for this post. I worked with a SAS Specialist and we identified that the issue was only occurring when trying to save in the default enhanced editor. When we opened the program editor we could save with no issues. He said he’d go digging for a solution, but a few days later the issue resolved itself. Our IT team is baffled as they said they hadn’t changed anything and the SAS Specialist never found a solution but things are working again.

[SASKiwi]

@cgates - Please update your post as answered in that case.

[JuanS_OCS]

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.