I had a similar problem. Turned out to be a DNS issue. Our DNS was running
on the DC. When the DC was down, NFS wouldn't work. All I had to do was add
our router as a nameserver in resolv.conf and it started working again. It
seemed to be that as long as OmniOS has someone responding to DNS request
We have a file server implementing CIFS to serve files to our users.
Periodic snapshots are replicated to a secondary system via zfs
send/receive. I recently moved services (shares, ip addresses, etc) to the
secondary system while we performed some maintenance on the primary server.
Shortly after e
I ran into the same issue when setting up my home server. Access to CIFS
works by IP but not name. I ended up setting up a second IP address and
created a DNS entry with a different name for that IP. I have no idea why
it works but it does.
Aaron
On Wed, May 13, 2015 at 6:10 AM, Dominik Hassler
Paul,
Thank you for the response. I was beginning to think that everyone thought
this wasn't even worth commenting on.
We have a couple OmniOS servers that have been running the in-kernel CIFS
server with Active Directory integration for a while now and haven't had
any problems. We've been very h
Hi all,
We have encountered an issue with out OmniOS CIFS file server and file
locks. Every now and then we get a call from a user trying to access a file
but they can't because it says that the file is in use by another user.
Long story short, we track down the session holding the lock, kill the
This server is currently running r151010.
Aaron
On Mon, Feb 9, 2015 at 12:41 PM, Dan McDonald wrote:
>
> > On Feb 9, 2015, at 2:41 PM, Aaron Curry wrote:
> >
> > Thanks for confirming that. We will be updating tonight. Hopefully we
> don't see this again!
>
Thanks for confirming that. We will be updating tonight. Hopefully we don't
see this again!
Aaron
On Mon, Feb 9, 2015 at 12:07 PM, Dan McDonald wrote:
>
> > On Feb 9, 2015, at 12:41 PM, Robert A. Brock <
> robert.br...@2hoffshore.com> wrote:
> >
> >
> > Smells like this:
> https://github.com/Ne
r151010. Can we assume that an update to
r151012 will fix the issue?
Thanks again,
Aaron
On Mon, Feb 9, 2015 at 10:41 AM, Robert A. Brock <
robert.br...@2hoffshore.com> wrote:
> >From: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] On
> Behalf Of Aaron Curry
>
Hi all,
We recently set up an OmniOS file server to serve our SMB clients. The
server paniced over the weekend. I was hoping someone here would help us
interpret the panic info and possibly point us towards a resolution. The
stack dump is:
panicstr = BAD TRAP: type=e (#pf Page fau
Johan,
It looks to me like your understanding of ALUA is correct.
Bottom line: ALUA is a way to present a LUN to a host while advertising all
possible paths. These "possible paths" include the local target HBAs as
well as any other target HBAs in the ALUA group. This is necessary in a
high availa
I had this exact same problem recently when setting up a new home server...
same controller, same firmware (P20). The errors were on all disks attached
to the controller, but only on high read activity. Writes did not generate
the errors. I downgraded the firmware to P18 (which is what we are using
11 matches
Mail list logo
