sabma + solidworks "access to unnamed file denied"

A couple things right away. Can you set priveledge in the component library so just one user is rw and the rest of the users are ro? Seems to me you don't want library files being changed by just anybody.

Second, is SW set to open referenced files read only? This will prevent users from getting write priveledge when they don't really need it and obviously stop a lot of contention.

I will think about this some more.

If you haven't already, take a look at the "suiddir" mount option, it'll help solve your problems.

man mount(8) ==================================================================== suiddir A directory on the mounted file system will respond to the SUID bit being set, by setting the owner of any new files to be the same as the owner of the directory. New directories will inherit the bit from their parents. Execute bits are removed from the file, and it will not be given to root.

This feature is designed for use on fileservers serving PC users via ftp, SAMBA, or netatalk. It provides secu- rity holes for shell users and as such should not be used on shell machines, especially on home directories. This option requires the SUIDDIR option in the kernel to work. Only UFS file systems support this option. See chmod(2) for more information. ====================================================================

Whoops. Linux doesn't have that mount option, and that man page snippet is from a FreeBSD system.

Looks like it's time for you to switch your file server OS from that half arsed Linux hackery to FreeBSD, eh?

;-)

I had an access problem with Access this morning getting to an Access database on a Samba server. It turned out that I had to set security settings in Internet Explorer to allow access to the Samba machine before Access would access it's database. This is all the more amazing considering that Access had been able to access the database when it created it on the Samba server.

Hi :)

In that case it is impossible to open any component by others, because sw want to write this ~$*.* thingy to share ??

There is 6 engineers, who use solidworks, and everyone have to have rw access to component library in nature.

We have next kind of userbase. 18 users (workers/management in company) and in case we go to use common unix/linux groups, we need 12 different groups for 12 different teams with different privilegies to shares. Each users have to have membership of approx. 4 to 5 groups. Then we have 25 shared directories.

This is quite common situation in small companies, lets say, that one engineer, who use solidworks, is allso manager, quality engineer and so on... one person, four chair.

If I use normal user, group, others privileges to access, I can quess, that it is mess. Or I feel so at least.

I choosed it that way. I created one group in linux, smbusers. I put all users to same group. This linux group is allso samba group via automagized linux group/users conversion to samba groups/users :)

All directories aka shares has same privileges (in linux filesystem level). Same owner (member of smbusers of course) and same group, smbusers. Owner and group has full access to share (rwx) and others don't have any access. This is in linux filesystem level.

Sticky bit is allso set.

Then privileges/access are performed by samba via smb.conf next way.

From my smb.conf:

[solid kompon] writable = yes path = /home/netshare/solid_kompon write list = some users read list = some other users invalid users = user who dont need to mess in this share force group = smbusers create mask = 0660 directory mask = 0770

I know, that this is quite crude way to handle situation, but I decided to make it that way for following reasons.

-I don't need to set up ACL

-I try to avoid mess with 18 users, 12 groups and multi membershipment to different groups and multi privileges to 25 different shares.

In the company there is quite strict rules, who can access what. This is because of ISO 900x quality standard, and it is choosed that way in company. I can't help it.

This was preface, thank you, that you had time and intrest to read it :))

No, I don't know how to make this, alltough this sounds essential. I can phone to local solidworks help center, but their abilities are concentrated to help normal sw users to solve their common every day problems, how to use software to make projects.

This sounds intresting, will you please explain something more about this ?

Will you please so, THANK YOU :))

I have couple of ideas left, in order of propability ...

I miss some needed entries in smb.conf

My choice to use samba for privilegies don't work with sw, for reason or other.

Something is wrong in LAN itself

SUSE samba is compiled with flags, wich make it incompatible with solidworks.

Win bugs or solidworks bugs ...

My ideas in practice for tomorrow:

Here is my current smb.conf. Whole global section and one share. All shares has same kind of configuration anyway.

We dont have domain.

smb.conf is created with webmin.

# Global parameters [global] include = /etc/samba/dhcp.conf logon drive = P: domain master = No map to guest = Bad User username map = /etc/samba/smbusers printer admin = @ntadmin, root, administrator logon home = \\%L\%U\.9xprofile printcap cache time = 750 cups options = raw netbios name = PALVELIN server string = PALVELIN, Procreator ldap machine suffix = ou=Computers default = global ldap suffix = dc=example,dc=com workgroup = PROCRENET logon path = \\%L\profiles\.msprofile os level = 65 ldap idmap suffix = ou=Idmap add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$

I will remove next entries:

include = /etc/samba/dhcp.conf logon drive = P:

We don't have dhcp nor logon drive, I don't have slighest idea, what these entries make in here...

default = global

We dont need this "default = global", I think... if someone try to access shares without proper username/password, he/she don't neet to get in anyway.

I will add next entries to [global] :

security level = user socket options = TCP_NODELAY SO_SNDBUF 8192 SO_RCVBUF 8192 I think, that "security level = user" is default, but anyway...

I was stupid enought to forget to add socket options. I think, that it should be wise to use greater SO_SNDBUF (16384 or

32768).

We have some other rare problems, and I bet, that socket options will solve them or at least most of them.

And share. This is same again. I put it here, so it is easier to comment.

[solid kompon] writable = yes path = /home/netshare/solid_kompon write list = some users read list = some other users invalid users = user list who dont need to mess in this share force group = smbusers create mask = 0660 directory mask = 0770

As you can see, samba takes care about privileges. I'm bit worried about force group, create mask and directory mask, if they mess my samba system, as it is said somewhere, that it is possible.

I will make these changes to smb.conf tomorrow. If there is not any difference, I will setup LAN with samba server and two workstations via simple HUB. That way I can count LAN problems out.

Maybe I have to go to traditional owner/group/others privileges in sw component library share ?? It is somewhat easier, since there is rw privilegies for engineers and IT-support, r privileges for CNC-operator, and denied access to all others. This in case, that this my way to let samba handle all privilegies just wont work with solidworks ?? This may be easy to make.

Thank you for your patience to read this text :)

Do you (or someone) have suggestions to smb.conf or other/better ideas ?

Youre bad ;)

I don't have that possibility now.

Sorry, didn't understood this (I thought, how to adjust setting from sw) .

Short answer, no. That is problem. When first user opens component, he opens it in rw mode. When other opens same component, he tries open it rw mode as well, and it is not possible. Result is error message "access to unnamed file denied"

In word/exell this works well. First user opens document in rw mode , (he has privileges to that document) it is opened in rw mode. If other try to open it rw mode, it opens read-only mode. It works as it is expected.

All shares has same kind of entries in smb.conf and all has same privilegies in linux file system level.

So this problem is sw only. Not throught samba.

This may sound bit paranoid, but sometimes I feel, that there is inbuild pits in MS software, wich prevent them to work properly with

3rd party software...

In SW menus: TOOLS/OPTIONS/SYSTEM OPTIONS/EXTERNAL REFERENCES

You will find checkboxes for Open Referenced Files Read Only and for Don't Prompt To Save Read Only Files. Check both boxes. Do this on all seats of SW.

The users can use FILE/RELOAD-REPLACE to get write permissi> >

...SNIP

..SNIP

Since I don't know linux/samba internal reguesting, this is good quess.

Requests to open files from different workstations travel over LAN in different IP packets anyway. There is allways time difference between requests. So first request to open file gets it rw mode and next request gets it read-only mode. That is how it works in paper and most of the time in real world allso. Server software just have to have enought buffers to store reguests and enought intelligence to examine, what it gives and who.

That is not the case in my problem, because once opened files stays reserved, until these ~$*.* files are deleted (or project is closed). Are they are accessed at "same" time or 1 hour later, doesn't make any difference.

So all users try to open/make these ~$ files rw mode and read-only mode is nothing for sw. Or linux/samba prevent all access to these files, since one user have it open.

From linux shell all privileges seems to be ok anyway ...

Thanks !! Uh, seems that I have some real hope for tomorrow :)

It is 01.00 here and I have to go to sleep.

I will post tomorrow something about results.

I know. But at least my file server works. :-)

k, I made changes to smb.conf and also ticked dont prompt to save read only files.

Both make system better to use. Actually it seems, that it works properly now.

Big thank you for help !!

Miikka

You are welcome. Those to check boxes are big trouble for a lot of people even when usings plain old windows without the Linux enhancement.

Hi :)

sw seems to use its very own access/project management system. This works in win-server env, but still not allways flawlessly, as it is told for me.

Anyway it makes things bit hazy in alien systems... I don't have slightests idea, why they don't use normal windoze access controll to file access (since it works) and build own project-access-system around it. Instead they use that ~$ thingy. It is just txt file, where is information, who opened part from object library...

With this samba/sw setup it works now that way, that first owner has read-write access to file and others read-only. So it works at least.

Alltough opening in read-only mode is _SLOW_ (tm). It seems, that samba checks permission to ALL files separately (-> slow).

In my smb.conf security = user , I try security = share next, and well see, if it helps.

There is allso other env variables to samba to control this. Never needed to use before, but I may test these allso.

Anyway critical problems seems to be solved now. Working env is usable and productive.

AFAIK no ... if there is not inbuild options in sw.

I know, that in sw you can make one project, where 1 part is rw to 1st engineer, other part is rw to 2nd engineer and so on... whether this work with samba or not, I don't have idea, because it is not tested. It may work ...

This is just general info for all. It seems, that SUSE 9.2 may have relativelly poor TCP/IP performance with inbuild settings. May be allso, that samba is compiled w/o well adjusted compiling flags. We tried to make real stress test, and we opened one project from two workstation at once, but it drove us to problems. Other workstation opened project as expected, other gave just errmssges.

This is not real problem, usually 2 of 6 engineers don't want to access same projet at same time.

Personally not, our IT support company is far too small :-P