caracteristicas de windows

Windows 10: no ve un disco en red.

Windows 10 no ve carpetas compartidas en un disco en red o NAS.

En la oficina tenemos distintos marcas de discos duros NAS o en red. En los modelos más recientes, Windows 10 se conecta sin problemas a los recursos o carpetas compartidas, sin embargo al tratar de conectarse a los modelos antiguos, simplemente no ve la unidad o disco en la red.

Esto es debido a que por defecto, las versiones más recientes de Windows 10, vienen configuradas de tal forma que sólo reconocen discos en red compatibles con la versión de Samba 2.0 o superior. Si el disco en red comparte los recursos o carpetas usando la versión 1.x de Samba, éste no es reconocido o visto por Windows 10.

Para solucionar este problema es necesario especificarle a Windows 10 que instale el soporte para la versión 1.x de Samba. Para ello hacemos lo siguiente:

1. En el cuadro de búsqueda de Windows escribimos “activar o desactivar las características de Windows” y oprimimos la tecla [Entrar]. Esto debe abrir la ventana “Características de Windows”.

2. En la ventana “Características de Windows” buscamos la carpeta llamada “Compatibilidad con el protocolo para compartir archivos SMB 1.0/CIFS” y marcamos o seleccionamos el cuadro de selección que se encuentra al lado izquierdo de dicha carpeta dando un clic sobre él.

3. Una vez activada la opción oprimimos el botón “Aceptar”. Aparecerá una ventana donde mostrará el progreso de los cambios. Si todo salió bien en dicha ventana aparecerá el mensaje de que es necesario reiniciar nuestra computadora. Oprima el botón “Reiniciar ahora”.

Una vez que se reinicie la computadora, intente nuevamente conectarse a su viejo disco en red. Ya debe de poder ver dicho disco y sus carpetas compartidas.

Si no es así, puede ser otra la causa del problema.

Espero y les sirva esta entrada. ¡Hasta pronto!

KUP-11011: the following file is not valid for this load operation

Al tratar de recuperar un archivo de respaldo de múltiples archivos de oracle con el comando impdp este marcaba error y no recuperaba el respaldo.

Dentro de los errores que me aparecían estaban los siguientes:

KUP-11011: the following file is not valid for this load operation
KUP-11014: internal metadata in file /data/backups/respaldo_03.dmp is not valid

Al parecer es un bug de Oracle en la versión 12.1.0.2.0. Para que funcionara correctamente la importación tuve que agregar el parámetro

ACCESS_METHOD=DIRECT_PATH

A los parámetros del comando impdp quedando de esta forma la llamada:

impdp system/******* remap_schema=ESQUEMA1:ESQUEMA2 tables=ESQUEMA1.TABLA directory=RESPALDOS parallel=5 dumpfile=respaldo_%U.dmp logfile=respaldo.log full=N TABLE_EXISTS_ACTION=REPLACE ACCESS_METHOD=DIRECT_PATH

De esta forma la importación de la tabla dejó de marcar el error descrito arriba.

Espero les sea útil. ¡Hasta pronto!

postgresql en mantenimiento

Servicio Postgresql en mantenimiento en Solaris 10

De pronto el servidor de reportes de Pentaho versión 5.4 dejó de funcionar, la aplicación no era cargada por Tomcat y su archivo log mostraba lo siguiente:

SEVERE: The web application [/pentaho] created a ThreadLocal with key of type [java.lang.InheritableThreadLocal] (value [java.lang.InheritableThreadLocal@4bace654]) and a value of type [org.springframework.security.providers.UsernamePasswordAuthenticationToken] (value [org.springframework.security.providers.UsernamePasswordAuthenticationToken@fc3ceceb: Principal: org.springframework.security.userdetails.User@0: Username: admin; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: Admin; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: Admin]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

Al parecer la base de datos Postgresql no estaba funcionando. Al ejecutar el comando siguiente con privilegios de root
svcs postgresql
para saber el estado del servicio regresaba lo siguiente:
bash-3.2# svcs -p postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
maintenance Dec_04 svc:/application/database/postgresql:version_94

La versión 9.4 de Postgresql estaba en estado de mantenimiento (maintenance), al parecer, debido a un corte de energía, la base de datos no se apagó por completo.

Se revisa por qué motivo el servicio quedó en mantenimiento ejecutando:

bash-3.2# svcs -x postgresql
svc:/application/database/postgresql:version_94 (PostgreSQL RDBMS)
State: maintenance since Fri Dec 04 16:52:05 2020
Reason: Method failed.
See: http://sun.com/msg/SMF-8000-8Q
See: postgres_94(5)
See: /var/svc/log/application-database-postgresql:version_94.log
Impact: This service is not running.

Revisamos el archivo log que indica el el comando anterior y la última línea mostraba lo siguiente:

[ Dec 4 16:51:04 Executing stop method (“/lib/svc/method/postgresql stop”) ]
waiting for server to shut down………………………………………………………[ Dec 4 16:52:05 Method or service exit timed out. Killing contract 1187 ]

Al parecer no se completo correctamente el apagado de la Base de Datos.

Así que se revisó si algún proceso del servicio aún había quedado corriendo con el comando:

bash-3.2# svcs -p postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
maintenance Dec_04 svc:/application/database/postgresql:version_94

Lo que mostró que no había otros procesos del servicio postgresql 9.4 corriendo. Si los hubiera habido, hubiera sido necesarios “matarlos” con el comando kill.

Y por último, para activar o poner nuevamente en línea el servicio de Postgresql se corre el comando:

bash-3.2# svcadm clear svc:/application/database/postgresql:version_94

Corremos nuevamente el comando svcs para verificar que el servicio está corriendo de nuevo:

-bash-3.2$ svcs postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
online 18:16:25 svc:/application/database/postgresql:version_94

Efectivamente, el servicio está de nuevo en línea. Iniciamos nuestro servidor de reportes de Pentaho y listo, el error se fue.

¡Espero y les sirva! ¡Hasta la próxima!