Subject: Firewall-summary - msg#00103

Previous Message by Date: click to view message preview

SUMMARY: chown not working

I received tons of responses to my originial post. I had read the man pages like 4 times, but for whatever reason, the paragraph about this issue didn't register with me - my apologies for that. Several mentioned that this is a security item, but when I worked on - and even taught HP-UX - the chown command would strip the special bits (SUID, SGID, Sticky) for this very reason. I *thought* Solaris worked the same way - at least up through 2.6, but it has obviously changed and I didn't note it. Thanks to the multitude of responses. Ron > All, > > I have run into another very strange situation on all of my systems. I log > on with my personal login id and in my home directory I "touch junk". > Assume: my login id is rondin, userid is 30006, group is user, groupid is > 100. > > "ls -al junk" shows: > -rwxr-xr-x 1 rondin user 0 Sep 26 junk > "ls -na junk" shows: > -rwxr-xr-x 1 30006 100 0 Sep 26 junk > "ypcat passwd | grep rondin" shows > rondin:jhfjhsjkfsjkh:30006:100:Ron D:/export/people/rondin:/bin/ksh > "which chown" shows > /usr/bin/chown > "ls -la /usr/bin/chown" shows > -r-xr-xr-x 1 root bin 6884 Jan 5 2000 > /usr/bin/chown > "ls -na /usr/bin/chown" shows > -r-xr-xr-x 1 0 2 6884 Jan 5 2000 > /usr/bin/chown > "ypcat passwd | grep root" shows > root:;ladjfkljf:0:1:Super-User:/:/usr/bin/csh > > Problem: > as myself, "chown root junk" results in (I've also tried other userids than > root with the same result): > chown: junk: Not owner > > I can still use chown as root and change ownership of files, but not as a > regular user. I also had my admin partner try it using his regular user > login and he experienced the same problem in his home directory. > > Anyone have any ideas as to what's going on? The file ownership id matches > my userid in the passwd file/map, but I can't chown a file. I can create, > edit, and even "rm junk" successfully. Ron Dinwiddie UNIX System Administrator Temple Inland Forestry Products Corp. (TIFPC) - Diboll email: rdinwid@xxxxxxxxxxxxxxxx Office: 936-829-1592 Fax: 936-829-6666 Pager: 936-630-7086

Next Message by Date: click to view message preview

Summary: file size limit issue?

> I received some very helpful suggestions. > > The problem is that we have a program that runs on NT that builds an > output file via Samba running on Solaris to and NFS server (Auspex and > Netapps) that initially starts out fast then slows to a crawl. Where it > begins to crawl has proven to be predictable. It right above the 4 gig > mark. > > o We upgraded Samba to 2.2.1a which was suggested. Ran a test with the > results being the same. > o It was suggested Auspex may be a problem. Thankfully we do have a > NetApps box. A test was done on the NetApps box but unfortunately the > results were the same. > o Someone suggested checking ulimit on the Solaris box. We have unlimited > set. > o I tried doing a straight NT to Unix copy. Although it didn't look quite > right while it copied, it did complete a 5.5 gig copy. I was able to > verify the integrity of the file. It looked good. > o Not only did we try 2 different NFS vendors hardware we tried multiple > file systems. All the same results. > o No problem Sun to Auspex. We build > 4 gig routinely. > o No problem building locally on NT. > o Used a file system with 80 gigs available. Space not an issue. > > > Thanks to all who contributed. It's still an open issue but all the > responses helped to knock some of the culprits off the list. Also helped > me to look into things I didn't think off. If we sort this out within the > next couple days I'll inform the group of what we find out. > > > -----Original Message----- > From: Stephen Reeves > Sent: Wednesday, September 26, 2001 9:10 AM > To: 'sunmanagers@xxxxxxxxxxxxxxx' > Subject: file size limit issue? > > We are experiencing a problem that appears to be a file size limit. We > can't seem to nail down what component may be the culprit. What happens > is we have a process that runs on NT and outputs a large file (5 gigs) on > our NFS server (auspex) via Samba (Version 2.0.7) running on Unix(Solaris > 8). Around 4 gigs the process slows down dramatically. It has run up to > 12 hours before we kill it. As a test we had the same process run locally > on NT and output locally and it finished in 1hr and 5 minutes. > > We have run this process from Windows 2000 and 98. The Unix server is > always Solaris 8. We have tried one rev back on Samba with the same > results (2.0.6). We run the same production process on a nightly basis > with smaller files being output without visible problems. > > Any ideas greatly appreciated. Thanks in advance for any one willing to > take time out to respond. I will be happy to summarize. > > Thanks, > > Stephen >

Previous Message by Thread: click to view message preview

SUMMARY: chown not working

I received tons of responses to my originial post. I had read the man pages like 4 times, but for whatever reason, the paragraph about this issue didn't register with me - my apologies for that. Several mentioned that this is a security item, but when I worked on - and even taught HP-UX - the chown command would strip the special bits (SUID, SGID, Sticky) for this very reason. I *thought* Solaris worked the same way - at least up through 2.6, but it has obviously changed and I didn't note it. Thanks to the multitude of responses. Ron > All, > > I have run into another very strange situation on all of my systems. I log > on with my personal login id and in my home directory I "touch junk". > Assume: my login id is rondin, userid is 30006, group is user, groupid is > 100. > > "ls -al junk" shows: > -rwxr-xr-x 1 rondin user 0 Sep 26 junk > "ls -na junk" shows: > -rwxr-xr-x 1 30006 100 0 Sep 26 junk > "ypcat passwd | grep rondin" shows > rondin:jhfjhsjkfsjkh:30006:100:Ron D:/export/people/rondin:/bin/ksh > "which chown" shows > /usr/bin/chown > "ls -la /usr/bin/chown" shows > -r-xr-xr-x 1 root bin 6884 Jan 5 2000 > /usr/bin/chown > "ls -na /usr/bin/chown" shows > -r-xr-xr-x 1 0 2 6884 Jan 5 2000 > /usr/bin/chown > "ypcat passwd | grep root" shows > root:;ladjfkljf:0:1:Super-User:/:/usr/bin/csh > > Problem: > as myself, "chown root junk" results in (I've also tried other userids than > root with the same result): > chown: junk: Not owner > > I can still use chown as root and change ownership of files, but not as a > regular user. I also had my admin partner try it using his regular user > login and he experienced the same problem in his home directory. > > Anyone have any ideas as to what's going on? The file ownership id matches > my userid in the passwd file/map, but I can't chown a file. I can create, > edit, and even "rm junk" successfully. Ron Dinwiddie UNIX System Administrator Temple Inland Forestry Products Corp. (TIFPC) - Diboll email: rdinwid@xxxxxxxxxxxxxxxx Office: 936-829-1592 Fax: 936-829-6666 Pager: 936-630-7086

Next Message by Thread: click to view message preview

Summary: file size limit issue?

> I received some very helpful suggestions. > > The problem is that we have a program that runs on NT that builds an > output file via Samba running on Solaris to and NFS server (Auspex and > Netapps) that initially starts out fast then slows to a crawl. Where it > begins to crawl has proven to be predictable. It right above the 4 gig > mark. > > o We upgraded Samba to 2.2.1a which was suggested. Ran a test with the > results being the same. > o It was suggested Auspex may be a problem. Thankfully we do have a > NetApps box. A test was done on the NetApps box but unfortunately the > results were the same. > o Someone suggested checking ulimit on the Solaris box. We have unlimited > set. > o I tried doing a straight NT to Unix copy. Although it didn't look quite > right while it copied, it did complete a 5.5 gig copy. I was able to > verify the integrity of the file. It looked good. > o Not only did we try 2 different NFS vendors hardware we tried multiple > file systems. All the same results. > o No problem Sun to Auspex. We build > 4 gig routinely. > o No problem building locally on NT. > o Used a file system with 80 gigs available. Space not an issue. > > > Thanks to all who contributed. It's still an open issue but all the > responses helped to knock some of the culprits off the list. Also helped > me to look into things I didn't think off. If we sort this out within the > next couple days I'll inform the group of what we find out. > > > -----Original Message----- > From: Stephen Reeves > Sent: Wednesday, September 26, 2001 9:10 AM > To: 'sunmanagers@xxxxxxxxxxxxxxx' > Subject: file size limit issue? > > We are experiencing a problem that appears to be a file size limit. We > can't seem to nail down what component may be the culprit. What happens > is we have a process that runs on NT and outputs a large file (5 gigs) on > our NFS server (auspex) via Samba (Version 2.0.7) running on Unix(Solaris > 8). Around 4 gigs the process slows down dramatically. It has run up to > 12 hours before we kill it. As a test we had the same process run locally > on NT and output locally and it finished in 1hr and 5 minutes. > > We have run this process from Windows 2000 and 98. The Unix server is > always Solaris 8. We have tried one rev back on Samba with the same > results (2.0.6). We run the same production process on a nightly basis > with smaller files being output without visible problems. > > Any ideas greatly appreciated. Thanks in advance for any one willing to > take time out to respond. I will be happy to summarize. > > Thanks, > > Stephen >