This page gathers common symptoms, their probable causes and safe resolutions, oriented toward administrators. All the proposed actions are non-destructive: when in doubt, start with the checks, and generate a support bundle (System → Maintenance) before any more advanced action.
For the concepts (volume, share, cloud destination, archiving, recall, snapshot), see the product overview. For the procedures, see the task guide.
Share access#
My SMB share does not appear / "the share does not exist"#
Common causes and checks:
- Access restricted to groups/users: open the share and check the list of allowed groups/users. If you access with an Active Directory account but the share only allows local accounts, access is refused. Add the desired AD group (or leave the list empty if the appliance is joined to the domain).
- Appliance not joined to the domain while you use a domain account: check the join status in the Domain view. Join the domain if necessary.
- Protocol not served: check that SMB is indeed enabled on the share (an NFS-only share does not appear in SMB).
- Windows-side cache: disconnect then reconnect the network drive, or test direct access to the share:
\\<appliance-ip>\<share>
I cannot write to a share (read-only access)#
- The share may be configured as read-only: check the option in its configuration.
- The user's/group's permissions do not allow it: check the list of allowed access and the folder's inherited permissions.
An NFS client cannot mount the share#
- Check the share's list of allowed NFS IP / CIDR: the client's address must be present.
- Check that NFS is indeed a protocol served by this share.
SMB shares are no longer served after a pool reconfiguration#
After a heavy pool operation (import/export, recreation, HA relocation), the data mountpoint may have been briefly unmounted, which can cut the SMB service. Safe checks:
- Check in Storage pools that the pool is properly imported and healthy.
- Re-apply the shares' configuration (re-save a share, or re-import the pool from the UI): this restarts the sharing service.
- If access does not come back, generate a support bundle before any more advanced action.
The appliance does not appear in "Network" under Windows#
Network discovery (WS-Discovery / mDNS) is active by default, but its display also depends on the client workstation:
- Check that the share is directly accessible by its path
(
\\<appliance-ip>\<share>) — if so, it's a network-neighborhood display issue, not a service one. - On the Windows side, check that network discovery is enabled and that the network profile is Private (the Public profile hides the neighborhood).
- The first appearance in "Network" can take a few minutes after the appliance starts.
S3 archiving and archived files#
S3 archiving does not trigger#
Checks, in order:
- Associated cloud destination: the volume or the share must have a default cloud destination. Without a destination, no file can be archived.
- Valid cloud destination: open the Cloud destinations view and check the endpoint, region, bucket and credentials. The destination's Test button quickly reveals a connection or credentials issue.
- Eligibility criteria: archiving targets cold files (based on age/size). Recent or too-small files may not be eligible. The first run of a new archive policy is a simulation (dry-run): nothing is archived until you have validated it.
- Failed operations: check the Archiving operations (and the Archive policies view) to see if an operation failed and its message.
An archiving job is failing#
Typical causes:
- Incorrect S3 credentials or insufficient rights on the bucket (read/write/delete required).
- Non-existent bucket or wrong region: the bucket must exist beforehand.
- Network connectivity to the S3 endpoint (firewall, proxy, DNS).
- TLS verification: an unrecognized certificate on the endpoint side can block the connection in production (only disable verification in a lab).
Fix the destination in Cloud destinations, then relaunch an archiving run.
S3 archiving does not resume after a replication failover (HA)#
In replication ("Option A") mode, the cloud destination's secret is not replicated to the second node (a design choice: the secret does not leave its originating node). After a failover, S3 archiving and recall remain blocked on the promoted node until the secret has been re-entered: open Cloud destinations, edit the concerned destination and enter the secret key again, then test. Also remember, for a complete DR, to join both nodes to the AD domain if your shares rely on domain accounts.
Slowness when opening an archived file#
This is the expected behavior during a recall: an archived file (stub) is re-downloaded from S3 on its first opening. The delay depends on the file size and the bandwidth to the S3.
- For a large file, opening can take time: it's the ongoing download. Once recalled, subsequent openings are fast (the file is hot locally again).
- If the opening fails rather than being slow, see "I cannot open an archived file" below.
A file appears "offline" (icon) under Windows#
This is normal: it's the indicator of an archived file (stub). It opens normally; Caelum recalls it automatically. No action is required.
I cannot open an archived file#
Checks:
- Cloud destination reachable: if the S3 is unreachable (network, credentials, endpoint), recall cannot complete. Check the destination in Cloud destinations. After a replication failover, check that the secret has indeed been re-entered (see above).
- Object present in S3: the object must not have been deleted on the bucket side outside the appliance.
- Archiving operations: check the Archiving operations view for a possible recall failure and its message.
If the problem persists, generate a support bundle and contact support.
Storage and pool#
How to check the pool's status#
The Storage view shows: total capacity, used space, disk health status and topology (mirror / RAID-Z). A healthy pool must indicate a nominal status. Watch the free space: a pool close to saturation degrades performance.
The pool is almost full#
- Launch an archiving run (S3 tiering) on the concerned volumes to push cold files to S3 and free up local space.
- Check the snapshots: they hold the space of data changed since their creation. A too-wide rotation keeps a lot of data. Adjust the number of snapshots kept in the schedule.
- Check the volumes'/shares' quotas.
The pool's topology (mirror ↔ RAID-Z) is fixed at installation and cannot be converted in place. Size the pool accordingly from the deployment onward.
A disk is in error#
Check the health status in the Storage view. In case of a failing disk on a mirror or RAID-Z pool, the data remains available (the pool is redundant) but you must replace the disk quickly to restore redundancy. Generate a support bundle and follow the replacement procedure with support.
Cannot disconnect an iSCSI target#
This is a deliberate safeguard: Caelum refuses to disconnect (or delete) an iSCSI target whose LUN is used by an imported pool — disconnecting it would break the pool. To release it cleanly:
- Identify the pool that uses this LUN (Storage pools view).
- Export or destroy that pool beforehand (an operation to carry out knowingly, after backing up the concerned data).
- The iSCSI target can then be disconnected from Storage → iSCSI targets.
Network and administration interface#
Certificate warning in the browser#
This is normal by default: the HTTPS certificate is self-signed. Accept the exception, or import a certificate from your authority via System → TLS certificate.
The interface is unreachable after an IP change#
The appliance switched to the new address. Reconnect at
https://<new-ip>/. If you lost access, use the VM's console to reconfigure
the address.
No more access to the interface after a restart#
- Be patient: at startup, the appliance imports the pool and starts its services.
- Check the IP shown on the VM's console banner (it may have changed on DHCP).
- Check that the VM indeed restarted on its OS disk (and not on the ISO left mounted, or an empty disk). See the installation guide for the boot order.
Updates#
No update is showing#
- Check the chosen channel (System → Update): the stable channel only offers proven versions; the beta channel offers release candidates. If you expect a recent feature, check that you are on the right channel.
- Check the connectivity to the update portal.
An update caused a problem#
A pre-update snapshot is taken automatically before every update. From System → Updates / Rollback, use this snapshot to return to the previous state. Then check your shares after restart.
Active Directory#
AD users cannot log in#
- Check the join status in the Domain view (Realm, joined state).
- Check that the desired AD groups are present in the allowed access of the concerned shares.
- Check the appliance's time: a significant time offset with the domain controller breaks Kerberos authentication. Check the NTP servers (Network tab).
After leaving the domain, access no longer works#
Leaving the domain removes the machine account: AD-based access no longer resolves. Re-join the domain, or switch the concerned shares to local/LDAP accounts.
When to contact support#
Before contacting support, prepare:
- The appliance's version (shown at the bottom of the sidebar).
- A description of the symptom (who, what, since when, reproducible?).
- A support bundle (System → Maintenance) — it contains the logs and system state with secrets masked, and contains no user data.
Going further#
- Concepts: product overview.
- Detailed procedures: task guide.
- Screen-by-screen reference: administration guide.